Re: another try at multithreading

[Eike Decker <eike@...>]

Hi

I am interested in lockfree data structures. 
In my case, I have separate lua states, running in their own threads. Could I
use your hashtable to communicate between two separate states? That'd be
awesome, especially if it was a simple lua library DLL that I could load in
each thread, allowing me to create a bridge without messing up with my C
implementation. If the hashtable allows to be nested (which I guess it does
already), a "main" table could be created that contains specific tables again
that can be initialized and used by separate threads. Or does your table needs
to reside in the same luastate?
Does your table allows a reading thread to wait until a value has been created?

Would be great.


Eike

> Hi,
> 
> this is a recurring theme in my thoughts: how to do (efficient)
> multitasking on Lua... with full data sharing between threads?  I
> really don't like the several-spaces solutions (LuaLanes, LuaTask,
> etc), because there's no nice and clean to pass complex data (like
> deep tables, closures, coroutines, etc) around at will.
> 
> The only other solution is LuaThreads, but since it uses a single lock
> for the whole main Lua Space, execution is almost completely
> sequentialised, negating some of the benefits of multithreading in the
> first place.
> 
> An obvious improvement might be to use finer locks, maybe one per
> mutable object; but a pthread mutex lock weights between 40 and 64
> bytes each.  way too much.  readers/writer locks are even bigger.
> 
> So, i'm exploring the opposite direction: lock-free structures.  so
> far, i have a simple lockfree hashtable with similar semantics to Lua
> tables.  I'd like to put it somewhere (LuaForge? this list? it's just
> a 4.6kb tgz) to start some discussions.
> 
> it's still a very early work, has passed only some very naïve tests,
> and has some obvious bottlenecks, and a few missing features (no array
> part, for example).
> 
> any comments/ideas?
> 
> -- 
> Javier
>