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

Re: Concurrent programming coming to JavaScript

Dear All,

Actors have good aspects, but they also have drawbacks that could lead to the same mess as
what we see today with locks and mailboxes. Let the two following actors be

    actor A : run() {                      actor B: void m() {...}
                  for (...) {x[i]=B.m();}           void n() {...}
                  for (...) {use x[i];}
               }

A has a loop and calls B to load the elements of a table x and then uses these elements. The calls from
object A are non-blocking and A's execution is only suspended when it uses the results of the calls.
An actor may have several threads running in parallel. Thus, in a case like the one depicted above, there
may be several methods ready to be executed on one (or worse several threads). I imagine the
nightmare that debugging such a system could be. The user does not control the number of threads.

The idea of actors was to let the system put as much of its power into action as possible. However, as not
everybody knows ;-)  multi-threading is not a tool to speed up application, but only to organize the behavior.
On a single-core processor, actors don't of course speed up anything. Moreover, on a multi-core system,
considering that each process accepts calls at any time, it is not possible to offer a message to a set of
processors and let the first ready processor accept it, which is fundamental to balance the load, for example.
Doing this task will require an extension and or a library, and we are thus out for a new run.

Nevertheless, I like the idea of using a method call, but the actor should be replaced by an object with a
*single* thread. A method  *is* a channel integrated in the receiver (Smalltalk!). The object (or its thread)
can just accept a subset of method calls ( instead of calling a set of in.read() ) to perform the synchronisation.

With this approach, the N-to-1 channels are easily represented, but what about the 1-to-N ? A 1-to-N
transmission amounts to sending a message to the first object that is ready in an array of objects (should have
at least a common interface). A buffered channels ? An object that defined a read and a write methods
scheduled by the object (an optimisation could even get rid of the thead).

    object A : run() {                      object C: void m() {...}
                  cc = new C[6]                       void n() {...}
                  alt {                               run() {.. accept m; ..}
                     cc[*].m();
                  }

This would make type-checking easy. The data would be taken care of by the receiver the way it wants
(encapsulation of the behavior). And there would be no need to define, instantiate and exchange channels.
It replaces channels, right ?

Best Regards,

Claude


Allan McInnes a écrit:
It's probably worth noting that Will Clinger (mentioned in the extract of
Brendan's blog) did a bunch of work on the Actor model of concurrency. So it's
possible that's the direction that _javascript_ will end up going for
concurrency. The Actor model shares a lot of ideas with CSP, but also has a few
key differences, e.g. asynchronous rather than rendezvous communications, and
message delivery based on the identity of the receiver rather than via channels
(Erlang, for those familiar with it, uses a message-passing approach along the
lines of the Actor model).

Of course, it's pretty straightforward to build a CSP-like channel-based
rendezvous messaging system on top of an Actor-style system, so Tom's idea of a
CSP library should be feasible even if _javascript_ does take the Actor route
instead of the CSP one. Either approach would be a vast improvement over
threads with shared state.

Allan



Quoting Tom Locke <tom@xxxxxxxxxxxxx>:

  
Hi All,

I find the following to be of extreme importance to us CSP lovers:

Brendan "_javascript_" Eich wants to include *useable* language-level
support for concurrency into _javascript_ 3

Key quotes:

	A requirement for JS3 (along with hygienic macros) is to do
something along these more implicit lines of concurrency support. In
all the fast yet maintainable MT systems I've built or worked on, the
key idea (which Will Clinger stated clearly to me over lunch last
fall) is to separate the mutable unshared data from the immutable
shared data. Do that well, with language and VM support, and threads
become what they should be: not an abstraction violator from hell,
but a scaling device that can be composed with existing abstractions.

	So here's a promise about threads ... JS3 will be ready for the
multicore desktop workload.

Link: http://weblogs.mozillazine.org/roadmap/archives/2007/02/
threads_suck.html

There is a growing belief that Ecmascript / _javascript_ is about to
become The Next Big Language. Static typing is being added, as well
as other "in the large" features. Performance is becoming competitive
with Java. I think it's already the most widely known language...

Some of you heavy-hitters really need to start up a dialogue with Eich.

Of course the future is always murky, but there's a pretty real
possibility that this is *the* opportunity to take the CSP ideas we
love mainstream. An opportunity such that has never existed and may
never again.

At *least* it might be possible to steer things such that the
primitives can support fine-grained, high performance CSP via a library.

Peter - remember your CSP workshops at Sun where you convinced (IIRC)
everyone except Gosling? Time for a re-run at the Mozilla foundation!
These open-source types are much cuddlier than corporate lackeys
y'know :-)

Time to act!

Tom