Re: Java Live | January 9, 2001

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Joseph,

Sorry about last mailing!  This one's more sober.

> I certainly hope there's a better way to do concurrent programming than
> the way I'm doing it now with threads, but it seems to me that JCSP/CTJ
> has [to] clear a big hurdle before it will win me over.  It not only has
> to provide a great toolkit for solving problems (such as JCSP/CTJ), but
> it also has to change the way I think about concurrent programming.

That's the challenge.  Current thread mechanisms break any object structures
you designed to represent your system - the threads can wander around at will.
Object structures are in any case an inadequate basis (IMHO) with which
to construct complex systems.  They break most of the software engineering
rulebook!  I find it very difficult to reconcile principles like abstraction
and information hiding with the concept of classes, objects and inheritance.
There are so many ways to intefere with an object, aside from its publicly
declared method interfaces.  And there are no ways to declare how objects
intefere with their environment (the event mechanisms of Java are not part
of the language - and it's not only GUI objects that generate events!).
An OO-system all too easily descends into a mess of global undeclared
interactions :-(

On the other hand, the JCSP (CSP) design pattern confines threads within
process boundaries and requires the explicit declaration of all ways in
which a process ineracts with its environment - i.e. we get abstraction.
CSP, itself, also gives us an algebra in which we can formally reason
about these interactions.  But, more important perhaps than the formalism,
data encapsulation does not break down (so easily), process algorithms
are expressed from the point of view of the process (rather than the point
of view of the invoking object - as is the case with method bodies) and
processes become *components* (i.e. they can be composed to form larger
components and we don't get nasty surprises when we do this).  A process
harmonises thread structures with data structures and this is heaven!

So, CSP is so much more than channel communication and the prevention of
generator threads overwhelming consumer therads - that Christopher talked
about on the Java Live show.

> I wonder if packages like util.concurrent will [always] be the choice of
> professionals for server-side development.  To convince me otherwise,
> build a high-performance web server in JCSP.  Or do something along the
> lines of Matt Welsh's Sandstorm project and show that your design is
> even "cooler" and performs just as well.
> 
> ( http://www.cs.berkeley.edu/~mdw/proj/sandstorm/ )

Thanks - I'll have a look at this (or get my students to :-).  JCSP primitives
are currently built on top of raw Java monitors.  So they suffer, but do not
increase, the same overheads.  Later releases may be different (e.g. they
may take advantage of our fast occam kernels - but that means native code).
Meanwhile, a JCSP web server could be no faster than any web server built in
100% pure Java - but it could be developed faster, be easier to maintain and
be bug free (well, at least I would feel very much more confident with it).

Have you checked out our occam-build web server?

  http://wotug.ukc.ac.uk/ocweb/

There's a brief description of how it works, performance graphs (against
Apache) and full source code.  The original highly parallel design and
implementation took one day - but it's been tweaked since!  There's a paper
I could send (from this year's CPA-2000 conference).

All the best,

Peter.