Re: LuaThreads with LuaJIT (and maybe lua_tcc)

[Javier Guerra <javier@...>]

On Tuesday 11 April 2006 1:23 pm, Mike Pall wrote:
> Then LuaThreads is not what you want. Apart from performance
> reasons (see below) there is a serious limitation: there is only
> a single lock around the Lua core. This means that only one
> thread at a time can execute Lua code. A thread can only run in
> parallel if it is executing C code which does _not_ call back
> into the Lua core (i.e. blocking in an I/O operation or some CPU
> bound C code).

that's very instructive, i was aware of the single lock issue, but hadn't 
realized that it prevents even pure Lua code from multitasking.

> I suggest you look into the mailing list archive for other
> approaches. You can use multiple Lua universes and connect them

this is what LuaTask does (http://luaforge.net/projects/luatask)

> with message queues. Or you can use helper threads to do some
> isolated CPU bound operations in C code (only accessing the Lua
> core at the start and end).

unfortunately, there's still no windows port of the Helper Threads Toolkit.

> [Note that all of this is not a flame against LuaThreads. It's an
> inherent limitation of the concept and not the implementation.]

other bytecode languages (those that start with j and p) solve this using much 
finer locks, in most cases one lock per data object, i think.  of course, the 
performance of both on the core VM and GC suffer heavily.

> Just registering the standard Lua libraries (luaL_openlibs)
> requires more than 1100 locks+unlocks! The heavy lock contention
> is bad enough for single CPUs and will slow everything to a crawl
> on multi-processor machines.

it would be interesting to compare the futex-based Linux pthreads and windows 
locks on this.  if i understand it right, locking and unlocking a futex is 
just a couple of asm instructions when there's no contention.


-- 
Javier

Attachment: pgpyQoGOdZ9d_.pgp
Description: PGP signature