Re: Lua State Thread Safety

Hi Thijs Schreijer

I did not understand understand two statements from you.

1. Keep the stuff you need 'anchored' in the lua state, then it will not be collected.

Kindly elaborate what you mean here....

2. BTW; did someone mention that top-posting is considered a bad habit around here?

Are you asking me to write the mail at top of mail chain.., but I found mostly all mails are down the line , and so followed, sorry if I understood wrongly.

Anyway, I am concluding

1. I will have my own lock (semaphore with default count 1), will lock / unlock as per my requirement

2. With this I assume I would not messup with lua state.

Austin

On Mon, Jul 14, 2014 at 2:14 PM, Thijs Schreijer <thijs@thijsschreijer.nl> wrote:

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Austin Einter
> Sent: maandag 14 juli 2014 8:56
> To: Lua mailing list
> Subject: Re: Lua State Thread Safety
>
> Hi Tim
> My worry is, with use of our own locks to protect Lua state , will garbage
> collection pose any thread safety issues.
> Say threads are T1 and T2
> Using lock, I can control T1 and T2, so that only one thread access Lua
> state at a time
> But garbage collection, in which thread context it executes

The thread that is currently active in the Lua state is the one that will do the garbage collecting

> Can it happen that, under T1 I am doing something, and with T2 garbage
> collection is being executed by system......, hence we will not be able to
> protect in this case as garbage collection code is not in my control.

Keep the stuff you need 'anchored' in the lua state, then it will not be collected.

>
> I have not see any issue, just want to make sure I am not doing wrong in my
> design.

Generally the tendency of people starting with Lua and multithreading is to stick to the paradigms they know, which is usually the concept of preemptive multithreading by the OS. I find Lua's cooperative model far easier to use. And if that can't be done, consider the option Andrew mentioned; multiple states.

The lock macros should really only be a last resort, because you will be importing the whole deadlock/racecondition misery of preemptive multithreading into Lua. Because they are fine-grained. If you use your own locks/semaphores, make sure a single call is completed before unlocking again to prevent this.

Thijs

> Austin
>

BTW; did someone mention that top-posting is considered a bad habit around here?