 |
lua-l archive |
|
|
||
|
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 inany time you do something in a child state, not only when youexplicitly 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