Multithreading and locking...

[Francisco Olarte <folarte@...>]

Hello everyone, I have a problem with multithreading...
For a program I'm doing I need to use a single interpreter from
multiple threads. I do not have problems in the normal case, just
lock/unlock around usage, but some times I need to "reenter".

I NEVER need to interrupt running lua code, but occasionally the
following will occur :

( I will use thread for OS threads and coroutine for lua ones )

1.- OS Thread A enters lua interpreter ( I normally do do this on
fresh coroutine ).

2.- ostA calls a C function I provide it. This function calls into the
C core and in some cases sends a message to os thread B, waiting on
its reply.

3.- ostB needs to call into the interpreter, get some data, do some
more work and reply to ostA.

4.- ostA gets the reply and return to Lua.


I was looking at lua_lock / lua_unlock but they seemed to happen a
lot, and besides I do not want two threads working inside the
interpreter at the same time ( to avoid data races ). So I was
thinking on:

a.- Whenever an OS thread wants access to the interpreter I lock it on
entering, unlocks on exit.

b.- Whenever one of my C funcions needs to call into the core ( to
something which may potentially need the interpreter ), I unlock the
interpreter before entering the core and relock it before returning.

>>From what I've read (in the source, like luaD_precall in ldo.c) when
lua calls a C function it surrounds it with lua_unlock(), lua_lock(),
so my locking will be a much stricter version of the normal version.
I'd like to know if this is "safe".

( I have an alternate solution. As I always enter the interpreter in a
coroutine I can lock/unlock around that and, whenever I need to call a
C function which may need to reenter yield a special token ( an LUD, a
fixed one for "magic yield" ) plus the call data in another LUD (
really a pointer to a runnable C++ object ), catch LUA_YIELD+magic
number, unlock the interpreter, call the core C function ( invoking
the runnable with the interpreter as a parameter ) and lua_resume()
after relocking, but seems like overengineering if the simpler
unlocking approach works ).

Any sugestions?

Francisco Olarte.