reddit discussion about Go turns to D again

[Russel Winder]

On Sun, 2011-05-15 at 05:53 -0400, Gilbert Dawson wrote:
[ . . . ]
> You could shed some llight on this if you're an expert. I don't know what's so different between actors and CSP. How does D support dataflow concurrency?

I like to think of myself as an expert on this . . . you'll have to ask
others if I actually am :-)

Actors -- An actor is a self-contained process that communicates only by
sending and receiving messages.  Each actor has a single message queue
that it processes messages from in its own time.  Message sending is
asynchronous.

Dataflow -- a program is a collection of operators that are connected by
channels.  Operators can have many output and many input channels.
Operators are event listeners, a computation is triggered by a certain
state of the input.  Message sending on channels is asynchronous.

CSP -- a program is a collection of single threaded processes.  Each
process can have many input and many output channels.  Channels have no
buffering, all message passing is synchronous (rendezvous).

Data Parallelism -- a computation is (effectively) the synchronous
evolution of an array where each element evolves in parallel.

There is also transactional memory, but unless it is supported in
hardware, there are some doubts about the ability of this technique to
scale -- though I have yet to find any real data dealing with this in
either positive or negative light.   Although software transactional
memory (STM) is getting some airplay in the functional programming
community (along with data parallelism), the HPC community is not taking
it up -- though this may be inertia.  Personally I am not a fan of STM,
it tries to make shared-memory multi-threading work when it would be
better to use a message passing architecture in the first place.

Scala (with or without Akka) spearheaded the resurgence of actor model,
though Erlang has been successfully using it for many years.  D has
picked up on it as well, it is part of std.concurrent and std.parallel.
As far as I know D has no support for Dataflow and CSP.

It is possible to implement actors with dataflow and vice versa but it
is much better to treat the two as needing two implementations founded
on a shared set of tools to handle message passing and locking.

GPars is bringing all of the above models to the JVM.  It's actor model
and dataflow support is it's own, CSP is provided via an adaptor to JCSP
(Kent University -- the one in the UK that is), and STM via an adapter
to Multiverse.

Why do all this?  To get rid of shared memory.  No shared memory, no
need for locking, sempahores, monitors, etc.  Message passing doesn't
guarantee no deadlock or livelock, but it is much, much, much better
that fighting shared-memory multi-threading.

I hope this helps.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110515/696702f2/attachment.pgp>