lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



Robert Raschke kirjoitti 20.6.2008 kello 20:23:

On 6/19/08, Javier Guerra <javier@guerrag.com> wrote:
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.

Programming efficient multithreaded applications requires a different
mindset from good old fashioned sequential apps. In particular "full
data sharing between threads" to me signifies an app doomed to fail
(i.e., hard to write and maintain). If you need to share "complex
data" you have not partitioned your problem correctly for a parallel
solution.

To get an indication on what "real" parallel apps can look like have a
read across some of the apps written in Erlang.

I think about the verbs in my problem space as providing hints for
parallization. The stuff that gets worked on on limits the
parallelism, that´s your data! The more you are thinking in terms of
data, the less you will spot any chance for parallelism and the more
you will become obsessed with getting your locks right.

Just my 2 cents worth,
Robby

Well said.

The Lanes programming model (with "futures" aka lazy evaluating function calls) allows such verbs to be glued together like in a makefile. It comes very close to data flow programming (LabView, anyone?). Parallelism is self-evident and kind of built-in in such a model. And it scales seamlessly, too.

About other issues mentioned:

Inability to pass over closures is due to Lua C API. Fix/enhance that, and Lanes etc. will gladly throw around closures. :)

This discussion has given me ideas on how to do the inter-state communications better, using intermediate state to keep the data before readers do read it. This would take off serialization from Lanes altogether, and make everything simpler. Will comment further once I've done it.

-asko