On Wed, Feb 16, 2011 at 11:10 AM, Russel Winder <rus...@russel.org.uk>wrote:

> Prompted by various discussions elsewhere, I am on the search for recent
> experimental results and/or people doing or about to do experiments.
> The questions all relate to the models of parallel software:
> shared-memory multithreading, Actor Model, Dataflow Model, Communicating
> Sequential Processes (CSP), data parallelism.
> Question 1 is:  is synchronous message passing easier for programmers to
> work with than asynchronous message passing.
> Question 2 is:  are the case classes of Actor Model easier for
> programmers to work with than the select statement of Dataflow Model and
> CSP.
I am not sure what you mean by "case classes of Actor Model".  You seem to
be using some implementation-specific terminology, presumably from the Scala
implementation of Actors.  For example, did you know that the Scala
implementation of Actors in the Scala standard library doesn't actually
impose fairness constraints on message delivery, and therefore isn't
identical to Hewitt/Agha's Actor Model(TM)?

When I heard Actor Model in capital letters, I think of the work done by
Carl Hewitt.  If you can refer to a place where Carl says "case classes", I
would appreciate that reference.  I've read most of his and Gul Agha's work
on Actor Model, and am not familiar with "case classes" vocabulary.

And what does "easier" here mean?  The original Actor Model was intended to
be used by semanticists for e.g. proving that a server always provides
service to its clients.  See Hewitt and Lieberman's AI Memo 505 for an
example of proving properties of a guardian in an actor language.

I also don't understand the "select statement of Dataflow Model".

I also reject the idea that synchronous message passing vs. asynchronous
message passing is a good topic for empirical study.  There are much bigger
theoretical issues like deadlocks and whether buffers are being used.  I
also see synchronous vs. asynchronous juxtapositioned without much thought
to the context.

It is all well and fair to say some researchers try to do studies without
background in cognitive psychology, but it is equally true that cognitive
psychologists peddle garbage studies without actually understanding how to
do software design and what are actually considered "trade-offs" or even

Moreover, most studies I see are biased, but being a cognitive psychologist
is certainly not enough to detect this bias.  You have to understand the
problem domain.  A classic example of this is William Cook's award winning
paper Web Services vs. Distributed Objects: A Case Study of Performance and
Interaction Design http://www.cs.utexas.edu/~wcook/Drafts/2006/WSvsDO.pdf

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