Re: another try at multithreading

[Asko Kauppi <askok@...>]

Good luck.

As a minor correction to your list of "deep tables, closures,  
coroutines etc.", at least Lanes has no issues with deep tables. Maybe  
you meant large tables (takes more time to copy back-forth) or  
recursive tables (not implemented, to favor speed). Anyways, for  
closures and coroutines the argument is valid.

There are these two ways of seeing parallelism. And networking /  
multiple processes can be seen as third.

-asko


Javier Guerra kirjoitti 19.6.2008 kello 6:05:

> 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