Re: Multithreading and locking...

[Victor Bombi <sonoro@...>]

Personally I prefer using lanes for running a different Lua_State in every OS thread (called a lane) and getting comunication between lanes with the lanes API.
You say that

> For a program I'm doing I need to use a single interpreter from
> multiple threads.

Are you sure you need a single interpreter?

> El 21 de mayo de 2019 a las 11:45 Francisco Olarte <folarte@peoplecall.com> escribió:
> 
> 
> 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.
>