[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Multithreading and locking...
- From: Francisco Olarte <folarte@...>
- Date: Tue, 21 May 2019 11:45:34 +0200
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.