Re: Which Lua API calls are safe for different Lua States in different threads?

[Graham Wakefield <lists@...>]

On Jan 14, 2007, at 4:50 AM, Chris wrote:

> On 1/14/07, Wim Couwenberg <wim.couwenberg@gmail.com> wrote:
> > Your greatest concern is the garbage collection cycle.  It can  
> > kick in
> > any time you do something in a child state, not only when you
> > explicitly request it.  This makes your approach unsafe.  Bottom  
> > line:
> > always allow only a single OS thread to drive the lua_State at a time
> > (use some mutex construct).

I only have two threads, but they do need to share lua values so one  
is necessarily the child of the other.

In my implementation, the child thread is the only one that can turn  
gc on or off, and it turns it off before any function calls, then  
turns it back on once it has finished; so far this appears to be  
safe.  Essentially, it means that gc can only happen when the child  
thread is not active, i.e. there is only one thread active on all  
lua_States.

The child state is in a high priority thread (an audio callback) so I  
can't really afford to put mutex locks over every interaction with  
Lua.  I therefore implement a mutex lock over the shared state, but  
it seems that the lock is only necessary for the duration of  
interactions  with the shared state.  By using an intermediate buffer  
lua_State (and lua_xmove()), I only need to put locks around  
interactions with this intermediate state, which minimizes my use of  
locks.  So far this also seems safe.

I don't know a great deal about thread locks, perhaps there is a more  
efficient way than the usual pthread mutex?  I'd love to know.

Other than garbage collection, are there any other operations on a  
lua_State that affect child/parent lua_States?

> This is only a problem with certain classes of code mostly dealing
> with userdata types.  For example releasing COM objects may need to be
> done from the correct thread.  As far as I know the Lua types and
> their collection are thread-safe.
>
> > The lua_lock and lua_unlock macros are not recommended: they slow
> > things down *a lot* because they are used often.
>
> I think this is a misconception.  Where is it not recommended?   It's
> highly dependant on how efficient your locking mechanism is and you
> get to determine the locking mechanism.  For example on Windows I see
> no measurable slowdown at all when using CriticalSection locking.  In
> my pthread version I see about a 25% slowdown but I'm using a slow
> implementation that has plenty of room for improvement.
>
> CR