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

Re: Concurrent programming coming to JavaScript

Hi everyone,
Yes, Allen gives an excellent summary of Actors, and I agree with Barry that it's worthwhile to explore the commonalities of the Actor model and CSP. I would recommend, in particular, Gul Agha's 1985 dissertation, "ACTORS: A Model of Concurrent Computation in Distributed System." Here is a link to the PS or PDF file, for your reading pleasure: :-) 
http://dspace.mit.edu/handle/1721.1/6952
One caution, which may not be immediately apparent as you read, is when Agha references CSP, it is Hoare 78 CSP, not the 1985 text version, which was published the same year as Agha's monograph. While I am not familiar with the dialect of Actors that Claude described in his reply, I would add the following to characterize one of the differences between Actors and CSP: CSP processes compose deterministically by default, but due to the mailbox infrastructure by which actors communicate, actors compose nondeterministically: message delivery is guaranteed, but order of delivery is not. In some sense, this is the actor equivalent of ALTing.
If misery loves company, the CSP and Actors communities share much in common: they are both largely misunderstood and under-appreciated general models of concurrency. They both have strong semantic foundations, and thus are reduced to sound-bites when described to, and dismissed by, the under-informed masses.
CSP and the Actors model share much common ground. My sense is that if an Actors implementation suffers from some of the same issues as threading models, it is likely an implementation issue, not the Actors model itself. 

-Marc

--
Marc L. Smith
Assistant Professor, Computer Science
Vassar College, Box 399
Poughkeepsie, NY 12604

e-mail: mlsmith@xxxxxxxxxxxxx
web: http://www.cs.vassar.edu/~mlsmith/



On Feb 22, 2007, at 2:51 PM, Barry Cook wrote:
Allan gives a very nice summary of the differences between the Actor model and CSP - but there are also very many things in common - or at least common desires. I found the article in http:// en.wikipedia.org/wiki/Actor_model VERY thought provoking. 

Maybe we are less out-on-a-limb than we think (?)
I need to follow-up some of the leads from this article, and other places. The Actor model has not been much mentioned in WoTUG (CPA) [as far as I can remember] - is there a good reason for this or should we be looking at it more seriously? 

     Barry.

Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE
CTO,
4Links Limited,
The Mansion,
Bletchley Park,
MK3 6ZP,
UK.
----- Original Message ----- From: "Allan McInnes" <amcinnes@xxxxxxxxxx> 
To: <occam-com@xxxxxxxxxx>
Cc: <java-threads@xxxxxxxxxx>
Sent: Thursday, February 22, 2007 3:09 AM
Subject: Re: Concurrent programming coming to JavaScript
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





--
Allan McInnes <amcinnes@xxxxxxxxxx>
PhD Candidate
Dept. of Electrical and Computer Engineering
Utah State University