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

["Gerald Hilderink" <g.h.hilderink@xxxxxxx>]

Doug Lea wrote:
> > but I am wondering more along the (imaginary) lines of what 
> if JSR 133 
> > that will tweak the Java memory model were to instead 
> radically alter 
> > it to a more transputer/grid/SMP/UML and ulimately user friendly 
> > sematics?
> 
> As I've argued for years now, I think that the classic 
> shared-memory/threads/locks/monitors and the classic 
> processes/rendezvous approaches are both reasonable bases for 
> some designs, but there is a vast middle ground that is not 
> optimally addressed by either of these.  And further, that 
> the middle ground is where many interesting and useful 
> programs are written. For random examples, Swing's 
> event-based messaging, RMI and JMS as messaging mechanisms, 
> fork/join synchronization, workflow, wait-free algorithms, 
> transactions, etc etc.

Oh, but the CSP model does address the middle ground optimally.
Actually, CSP addresses the higher and lower grounds optimally as well.
Unfortunately, CSP is not well-known by most of us and it has been an
university/research topic for too long. These last years CSP has been
undergoing new developments for use in practice. It has become excellent
and very useful for developing software for embedded real-time systems.

You treat CSP channels in your book "Concurrency Programming in Java"
2ed., excellent, but this is just a faction of what CSP is and can
offer. CSP offers a complete solution and it offers a glue logic that
will bring most topics in your book together as one complete and
consistent story. CSP offers an elegant and natural way of thinking and
reasoning about concurrency. 

This can be explained by the fact that multi-threading is NOT
object-oriented and CSP is object-oriented. CSP can be seen as a set of
design patterns encapsulating the hazardous and complex world of
multi-threading. Oh, and CSP offers compositional programming.

I guess, you could write a whole book about CSP for Java and people will
love it, because the book will provide them an (almost) "complete"
guideline for developing concurrent (real-time) software in Java in a
rapid and reliable way. There are not many books doing that. You will
love it because it is the right way to deal with concurrency.

Furthermore, CSP improves the UML concurrency model impressively (which
I am working on) and the CSP diagram (a new candidate UML diagram)
brings structured methods and OO together (more advanced than ROOM
does). Think of data-flow modeling and specifying true reactive behavior
in the UML :-).

> 
> 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.
 
> For example, it points out cases where updates to a variable 
> by one thread MAY be completely ignored by another thread. In 
> general, any race condition due to lack of use of 
> "synchornized", "volatile" and/or "final" may (but need not) 
> be optimized away by compilers, CPUs, cache controllers, DSM 
> subsystems etc. The main parallel to messaging is that both 
> parties must cooperate in order to reliably communicate via a 
> shared variable, but here the cooperation is mainly just via 
> declarations (synch/volatile/final).

Aha, good, so they slightly move towards the priciples of CSP. I think,
they should go for CSP and from there they should go further. This would
be easier and reasonable.

> 
> It would be great if this helps propel better unifying 
> frameworks, possibly some new language constructs, and 
> ultimately some better underlying theory.
> 
> While I'm at it, I should mention that JSR121 (See 
http://jcp.org) is also of interest to this group. It will introduce
(probably not until release 1.5) a new lightweight process-like entity,
tentatively called an "Isolate", that runs in a separate "address space"
than any other thread. It shares JVM resources, but no
programmer-accessible resources (so, no shared variables).  So you will
finally be able to get process-style semantics in Java without starting
up a new JVM, although it will be extremely challenging to make these
lightweight enough to be used as CSP-style processes in typical
CSP-style designs. Communication across Isolates can be achieved via
RMI, and possibly other mechanisms.

Yes the JSR121 is interesting, but I also belief that the CSP121
(kidding here) would be very interesting for the JCP group. They should
define "process" as in CSP and they can get rid of names like, Isolate,
Capsules, Active, etc. The CSP process encapsulates all these
definitions. IMHO, they should play with JCSP or CTJ so they can
experience the look and feel of CSP.

Gerald Hilderink