Tables and multithreading

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

Tables and multithreading

Framework Studios: Hugo
Hi,

If a new thread is created with lua_newthread, can I in that thread create a table, add it to another global table (List) and use that other table to access the first table in the main thread?

In other words, can I do this:

List = {}

-- called from 'other' thread
function ListV3D(x, y, z)

-- ... lock so List isn't accessed simultaniously ...

local entry = {}
List[#List + 1] = entry

entry.x = x
entry.y = y
entry.z = z

--- ... unlock ...
end

-- called in 'main' thread
function DoList()
-- ... do the lock thing ...

if #List > 0 then
  local i = 1
 while List[i] do
  local entry = List[i]
  -- ... do something with entry ...
 i = i + 1
 end
 List = {}
end

-- ... unlock ...
end

I am getting some weird crashes, not sure if it is because the above is invalid in some way...

   Thanks!
Hugo

Reply | Threaded
Open this post in threaded view
|

Re: Tables and multithreading

Javier Guerra Giraldez
On Thursday 16 March 2006 5:40 am, Framework Studios: Hugo wrote:
> Hi,
>
> If a new thread is created with lua_newthread, can I in that thread create
> a table, add it to another global table (List) and use that other table to
> access the first table in the main thread?

AFAICT, lua_newthread() is only safe out-of-the-box if only one thread is 
being executed at any given time.  that is, if you don't use OS 
multithreading to call each lua thread from different OS threads.

the lua core calls lua_lock()/lua_unlock() at key points, but these are 
defined out by default.  if you want to make lua threadsafe you have to 
define these macros.

the LuaThreads package from Diego Nehab does exactly that.

the downside is that there's a single big lock for each LuaState, not one for 
each lua object, so the concurrency is pretty low.

the other way to do concurrency in Lua is to have different and separate 
LuaStates, one for each OS thread.  then the problem is how to pass data 
between them.  Thas's the basis of the LuaTask package by Daniel Quintela

-- 
Javier

Attachment: pgpIzaRRxzjQQ.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Tables and multithreading

Mark Hamburg-4
on 3/16/06 4:06 AM, Javier Guerra at [hidden email] wrote:

> the downside is that there's a single big lock for each LuaState, not one for
> each lua object, so the concurrency is pretty low.

The lock is also acquired and released with high frequency if you spend much
time calling C code (including the standard Lua library) and even without
contention this tends to sap performance on a multi-processor machine
because it forces lots of instruction and memory syncs.

Mark


Reply | Threaded
Open this post in threaded view
|

RE: Tables and multithreading

jdarling
In reply to this post by Framework Studios: Hugo
> The lock is also acquired and released with high frequency if you spend much
> time calling C code (including the standard Lua library) and even without
> contention this tends to sap performance on a multi-processor machine
> because it forces lots of instruction and memory syncs.
> 
> Mark

This is true, about the only way around it would be to surface some type
of locking mech that could be leveraged in addition to standard locking.
 Something like critical sections that would override the standard
locking.  This was of course why I mentioned spin locks as they are
supported at the processor level and (from what I have read and used)
are much faster then software or OS level locking mechs.

 - Jeremy

"Help I suffer from the oxymoron Corporate Security."



Reply | Threaded
Open this post in threaded view
|

Re: Tables and multithreading

Dave Dodge
On Mon, Mar 20, 2006 at 11:08:15AM -0700, [hidden email] wrote:
> This was of course why I mentioned spin locks as they are supported
> at the processor level and (from what I have read and used)

One issue with spin locks is if that if you've only got a single CPU,
then when there is contention the process that needs the lock will end
up spinning for its entire time slice.  This time would probably be
better spent rescheduling the lock holder so that it can finish up its
work and release the lock.

> are much faster then software or OS level locking mechs.

System call overhead can certainly be a problem if you're doing a lot
of locking operations.  In the case of Linux there's a "futex" locking
mechanism that only requires a system call when the lock is actually
contended.  I'm pretty sure NPTL, the latest POSIX threading
implementation on Linux, is built around futexes.

                                                  -Dave Dodge