RE: The future of CSP? (OO & CSP)

[Doug Lea <dl@xxxxxxxxxxxxx>]

I'll stay away from all the religious arguments, but one of
your comments surprised me:

> > The new Java Memory Model (JMM -- JSR133) is not an 
> > earth-shattering revision -- it mainly just clarifies 
> > atomicity, visibility, and ordering rules (replacing the JLS 
> > spec chapter 17). But in doing so, it helps reveal the 
> > underlying continuum between shared-memory and messaging. 
> 
> It does not help "us" at all. I have read a draft of the Java Memory
> Model and it's so-called flexibility has become inaccessible. I decided
> to put it away and I hope this API will not become part of Java. The
> complexity that comes with this API will only hurt the popularity of
> Java. CSP already deals with these matters a decade ago

There is no "API" in the JMM JSR. It is a collection of rules
surrounding compilation and execution, along with their consequences
for Java-level semantics. Machines, especially SMPs, have gotten
substantially more complicated over the past decade (caching,
out-of-order execution, CPU-level parallelism, etc).  Unless you'd
like concurrent programs to be well-defined only on the kinds of
machines they made a decade ago, such rules appear necessary.  (Said
differently: The notion that "sequential" computation is purely
sequential is now false.)  But in CSP-style applications, only those
people implementing message-passing primitives etc will need to deeply
understand these rules. Similar comments apply to other styles.

-- 
Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA
dl@xxxxxxxxxxxxx 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/