Joseph Bowbeer (I think) wrote:
> I might recommend JCSP, too, if I were more familiar with it.
OK - I have to jump in ;-) ...
JCSP is a class library that provides an extended CSP model of concurrency
for Java. This is simply a world of process networks. A process encapsulates
its own data and algorithms - *only* that process looks at that data and
executes those algorithms (in its own threads of control). Processes
interact only through various kinds of *synchronisation* - the most common
of which is channel communication (which can be point-to-point, any-to-any,
zero-buffered, n-buffered, infinite-buffered, overwriting etc.). But
there are also n-way barriers, CREW locks and, if you want, you can use
standard Java monitor locks (but I'd advise steering clear of wait/notify,
because their semantics are so complex and non-compositional)!
The point is that processes only ever interact through well-defined
(in fact, formally defined) synchronisation primitives.
A process network is also a process - so the paradigm encourages layered
design patterns which correspond very naturally to real world structures.
Note that processes interact only with their given sync primitives (e.g.
channels, barriers) - not with other processes. So, a process deep down
in one layer of network hierarchy inetracts with another process deep down
some other layer *directly* through the common sync primitive they use.
This means there are no layers of hierarchy to climb at run-time - which
makes for high performance from highly structured designs.
The really nice thing about this is that the logic of innermost processes
(those that are not themselves a parallel network) is entirely sequential.
We reuse all our old serial processing skills/intuitions and they work. The
external synchronisations are viewed just as I/O operations that may block.
No one's going to interfere with your data structures. It's easy! That's
why the "S" is important in "CSP" - Communicating Sequential Processes.
So, parallel design skills and sequential design skills don't interfere
with each other. When we compose CSP processes together in a network,
we get no surprises - the semantics is compsitional (which is definitely
not the case with Java's synchronized/wait/notify ...).
I've watched with awe (horror!) the attempts at concurrent interaction
that tries to avoid synchronisation - all of which, I'm pretty sure,
will not work. I guess I was brought up in a different school!
In 1984, INMOS brought out the transputer. This had *no* cache and was
not designed for shared-memory multiprocessing. Nevertheless, it was
a wonderful multiprocessing component both externally (with its links)
and internally (with its hardware implemented synchronisation codes).
When we multiprocessed on a transputer, we always synchronised to
communicate - even though there were no cache problems and no other
physical processors jumping in (i.e. we *could* have got away with it!).
But we didn't for two reasons. One - the code was *much* simpler if
we followed the CSP rules (see above) ... we could reason about things
easilly and we could use formal methods and CSP analysis tools. Two -
the cost of synchronisation was trivial - around 600 nano-secs, courtesy
of the transputer's special sync instructions. We're only just beating
those times (with carefully written software, of course, schedulers) on
modern processors - year 2000 just beginning to outpace 1984 - we lost
something somewhere. [We're down to around 100 nano-seconds for a channel
communication in our CSP kernel for a (500 MHz) PC/Linux ... we're looking
to build this into a JVM to support the JCSP classes directly ... we're
also looking to build this directly into Linux ...]
So, we weren't afraid to synchronise - we *loved* to synchronise becuase
it didn't hurt and it made things so easy to program :-).
People designing new multiprocessors have got to relearn some lessons!
You can't synchronise processes (threads if you prefer) with ordinary
loads and store, you need special instructions - else it gets expensive,
messy and stands a good chance of being wrong. People writing multi-
processing software have got to relearn exactly the same lessons - you
can't communicate between processes using ordinary reads and writes,
you need special synchronisation primitives - else as before. In both
cases, of course, you need a good model of processes and synchronisation
- hence CSP ...
JCSP may be downloaded from:
http://www.cs.ukc.ac.uk/projects/ofa/jcsp/
Please also check out the Communicating Process Archotectures 2000 meeting
starting this Sunday:
http://wotug.ukc.ac.uk/cpa2000/
where all these things will be in the cauldron - follow the "Academic
Programme" link from the sidebar ...
The PC/Linux kernel mentioned above is part of the GPL'd open-source KRoC
occam system - from:
http://www.cs.ukc.ac.uk/projects/ofa/kroc/
Cheers,
Peter Welch.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT