Meredydd Luff's is an interesting study and paper.
However,

(1) The title is explicit that this was about PARALLEL programming,
and that's what the task was.  The results from a CONCURRENT programming
task might well be different.  For parallel programming, something like
HPJava might be better.

(2) Decades ago, designing Concurrent Pascal, Per Brinch Hansen realised
that a huge benefit in writing concurrent code came from the things that
the compiler *wouldn't* let you do.  He came to despair of getting other
language designers to see this.  If you take a sequential programming
language focussed on smashing variables as its main technique, and you
add concurrency features to it (which is pretty much how Java was designed),
you get all the old problems as well as all the new ones as well as all the
ones resulting from combining them.  Part of the reason for the washout in
this study must have been the sheer difficulty of doing almost anything in
Java, and another large part the difficulty of manually checking for the bad
things an issue-aware compiler would have ensured couldn't happen.
I mean, how do you write reliable concurrent code in Java without
understanding
the Java memory model?  And how many of us *DO* understand it?

(3) About the message passing/actor model: "I do not pretend that this
grafting of isolation onto a shared-memory language is an elegant one --
merely that it models the user experience I wished to emulate."
But it DOESN'T model the user experience that I get in languages like
Occam, Ada, Go, Inferno, Concurrent ML, or Erlang.  First of all, in Go,
Concurrent ML, Occam, and Erlang, processes are lightweight.  i would no
more worry about creating a few thousand processes in CML or Erlang
than I would about a few thousand interface calls in Java.  Second, for
all of those languages except Erlang, message sending is type checked.
(Sing# does this quite nicely.)  But the Java version shown in the paper
defers this checking until run time; a string must match a method name.
This makes message sending bothersomely slow (instead of pleasantly
fast) and dangerous (instead of being exactly as safe as a procedure call).

Above all, it doesn't seem to be the message passing approach at all,
but rather "information-bearing interrupts".  All the languages I mentioned
above that support something like message passing have *selective
receive*.  Information arrives at the receiving process ONLY when it
asks for it, only when it's ready for it, and the receiving process can
choose exactly which communication channels it is willing to listen to.
The paper describes a scheme where the sender *FORCES* a method
call in the receiver.  This is a very very different model of who is in
charge.

I would have said that plain old Java processes communicating through
ConcurrentLinkedQueue s would be a closer emulation.  (Amongst
other things, it's type checked.)

Are the materials available anywhere? I couldn't see them at
http://www.cl.cam.ac.uk/~wmfl2/



-- 
The Open University is incorporated by Royal Charter (RC 000391), an exempt 
charity in England & Wales and a charity registered in Scotland (SC 038302).

Reply via email to