Yet another Lua thread question

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Yet another Lua thread question

D Burgess-4
I am stitching Lua into an existing threaded application and I
was hoping that someone can confirm some things for me.

The app has a fixed threadpool, mutex protection guarantees that
only one of these threads can access the Lua universe (L) at
any one time.
The worker threads may load lua code and this code is
lua_resume()d, so that each OS thread has its own Lua
thread(L1, L2 ...). Again let me state that each of these
threads are mutex protected so that none of these states
are ever accessed by more than one OS thread at a time.

When the pool mutex is released another thread may begin
execution and the current thread immediately requests  the
same mutex, i.e. a pool thread may be preempted

There are no lua_yields. The lua_resume is simply used
to maintain separate Lua stacks for each OS thread when
it executes Lua code.

I have read (about 5 times) the blue PIL section at chapter 30
and have checked the Lua source (as far as I understand it)
and I think this is safe. Nor has it crashed on me (yet).

Can someone with great wisdom either confirm this is OK
or alternatively tell me what is wrong with this scheme?

David B
Reply | Threaded
Open this post in threaded view
|

Re: Yet another Lua thread question

D Burgess-4
> Can someone with great wisdom either confirm this is OK

Best guesses will do.
Reply | Threaded
Open this post in threaded view
|

Re: Yet another Lua thread question

Doug Rogers-4
In reply to this post by D Burgess-4
D Burgess wrote:

> Can someone with great wisdom either confirm this is OK
> or alternatively tell me what is wrong with this scheme?

It's the "great wisdom" part that is preventing you from getting
answers! Who wants to claim that?

I have always used separate Lua universes in each OS thread and passed
data between them, so even my tiny wisdom isn't enough to reassure you.
But it sounds like you've done the proper thing and the proper analysis,
and the proof is in the pudding - your application runs.

Of course I know where you're coming from. I just found a latent bug in
some of my very old, seemingly very reliable code where I forgot to
initialize a semaphore (pthread mutex/cv combo) that was being used to
synchronize thread destruction for an associated object. The code
ignored the error returned by pthread_wait() so it took a lot longer to
track down than necessary. A new regression test had put the system
under enough stress that the thread and its object were not properly
cleaned up in sync. Segfaults ensued.

The lessons are obvious. Try to have nasty regression tests and make
sure you check all return values, even if it's just to print a message
somewhere about it.

Doug