Re: Thread-support in LUA

[Mark@... (Mark Ian Barlow)]

In message <19970908210724.58827@home.chat.net> David Jeske wrote:
 > On Tue, Sep 09, 1997 at 12:00:25AM -0300, Bret Mogilefsky wrote:
 > > cooperative multitasking, meaning each thread has to yield in order for
 > > other threads to run and data is shared among the tasks.  You're right
 > > in that collecting the globals together per task is the main thing, but
 > > there are some other concerns.  In particular, Lua uses recursion for
 > > its call stack... This is fine without multitasking, but as soon as you
 > > add multitasking to the mix things get complex.  What happens if, say,
 > > you have functions calling back from C to Lua in one task, so your
 > > frames look like this:
 > 
 > However, what both of us were talking about won't run into this problem.
 > We were not going to share data and have a concept of "multiple-lua"
 > threads. We effectively just want to be able to instantiate multiple
 > copies of the "lua environment", each in it's own thread, but completely
 > separate. 

There's a terminology confusion here, I think. Traditionally "threads" are
lightweight, and all share the same stack while "processes" are completely
independent as David describes. Threads do not *have* to share other data,
however, and current thinking amongst most formal methods folk is that they
shouldn't be *seen* to (from the user's point of view) even if they actually
*do* at the implementation level.

On this basis I'd say David is on the right track, but Bret has a point: You
couldn't preemtively multitask between your threads unless they each had a
protected stack space, because if you did a longjmp() to some point inside
a previously suspended thread it might subsequently walk all over the call
stack of the one you just suspended. The only way you could make this work
using a single stack would be if each thread's stack requirements were
statically determinable at compile time (with Lua? no chance!).

Pragmatically then, fork/join would be the best way to get things working
quickly, and pipes could be used for communication. David doesn't say (this
confuses me a bit) that he wants to multitask his Lua sessions and communicate
between them but I don't see what use they would be if you couldn't; If you
just want multiple independent sessions surely you just spawn them from a
shell script? I suppose this goes beyond ANSI C, however; such a "Parallel
Lua" would really need POSIX compliance as well. To go the other way would
need, as Bret says, the splitting off of Lua's call stack from C's and it's
incorporation into a "Lua_Thread" structure along with the globals.



A lot of the basic theory for multitasking derives from C.A.R. Hoare's work
at Oxford University here in the UK. IMHO, the designers of Java slipped up
badly when they used his earlier concept of monitors (ie: 'synchronised'
methods) rather than his later and much superior CSP ("Communicating-
Sequential-Processes") model as used (but not exclusively) in Ada. In the
former, a thread-safe application *can* be written, with due discipline;
in the pure form of the latter it is impossible to write an un-safe one.

Note that it is still possible under both schemes to write an application
that will deadlock, ie: halt because a closed loop of processes are all
waiting for their predecessors to perform some action before they can
continue. If you want to avoid this you must analyse your program using
higher-level concepts; Eg: restrict yourself to a client-server model and
ensure that if closed communication loops exist then the client => server
direction is always either "clockwise" or "anti".



I write embedded (sometimes quite safety-critical) multi-processor robotic
applications and I've been using an obscure parallel processing language
called 'occam' for years now. See http://www.hensa.ac.uk/parallel/occam/
if you're interested. It's based on CSP, with strict type-checking applied
to communications (and assignments too, of course). The confidence, and
hence productivity you gain from not being allowed to make mistakes is
well worth the frustration of seeing a few extra compiler errors, believe me!

I'm not suggesting Lua needs strict typing BTW, just that it *doesn't* need
<yuck> shared memory. I suppose what I *am* saying is that multi-threaded,
multi-tasking programming is only ever going to be much fun to do on a large
scale if you have a lot of compiler support, which goes against Lua's spirit
somewhat.  Java people struggle and thrash around trying to coordinate of the
order of 10 threads; Ada pushes that envelope a bit, and occam allows me to
cope easily with 100+ but only at the expense of great formality in the
language: The pre-compilation checking must be > 80% of the total
compiler code!

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    Mark@nlcc.demon.co.uk            Voice / Fax: +44 (0)1207 562 154