[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaThreads with LuaJIT (and maybe lua_tcc)
- From: Mike Pall <mikelu-0604@...>
- Date: Tue, 11 Apr 2006 23:08:10 +0200
Hi,
Javier Guerra wrote:
> unfortunately, there's still no windows port of the Helper Threads Toolkit.
You could borrow the Windows pthreads emulation layer found in
LuaThreads. It should have most functions you need.
> 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.
I'm not sure this is feasible for the Lua core as it is now. One
could avoid stack locking, except that upvalues may point to
other stacks (ouch). Table and global string table locking is
straightforward. But userdata locking would need new API
functions. And then there's the incremental GC ... oh well. :-/
> 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.
Any recent glibc with NPTL and a recent kernel will use futexes
for pthread mutexes.
But this lock _is_ heavily contended. This means
a) a kernel call for all threads involved for each (un)lock and
b) a lot of ping-pong traffic in the multiple CPU case.
Bye,
Mike