Re: hook question

[Glenn Maynard <glenn@...>]

No need to CC me.  I'm subscribed to the list.

On Thu, Oct 12, 2006 at 11:19:43AM -0700, Mark Hamburg wrote:
> on 10/11/06 7:36 PM, Glenn Maynard at glenn@zewt.org wrote:
> 
> > I noticed those.  It's a roadblock to multithreaded Lua, at least for
> > my purposes.  (I'm also not sure about performance with the constant
> > locking and unlocking.)  Generally threading Lua would be extremely
> > useful to me, but I don't feel safe in taking that plunge just yet.
> 
> The locking overhead is pretty severe on an MP system even in the absence of
> contention because locks tend to also impose memory and/or instruction
> barriers.

Locks that function like Windows critical sections, which use user-space
interlocked instructions for the fast path (locking when not already
locked), should be very fast, I think.  Unfortunately, not all
architectures are capable of that.

Currently, for every place that I initiate Lua operations (eg. outside
of functions that take a lua_State), I acquire and release Lua explicitly:

lua_State *L = LUA->Get();
    use L;
LUA->Release(L); // unlocks and sets our local L to NULL so we don't use it accidentally

(I use it for coarse-grained locking, and it also checks for stack
balancing.)

In principle, I could change Lua's internal locking to require that
lua_lock be called externally.  Then, internally (eg. lapi.c), only
assert that it's locked in places that currently do it.  That way,
higher-level operations (eg. luaL_ref) would only lock and unlock
once, and would be somewhat more coarsely locked (luaL_ref would be
threadsafe).  The lock would still be in Lua's control, and would
still be a nonrecursive mutex, so Lua can still release the lock in
luai_threadyield, deeply nested calls can still unlock the mutex for
expensive non-Lua operations (file reading, 3d rendering), and so on.

(If it's used for eg. threadsafing luaL_ref, then the cases where the
lock might be released for things like luai_threadyield would have to be
strictly defined, though.)

-- 
Glenn Maynard