CSP and the middle ground

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

(Catching up on past traffic ...)

A while back, Doug Lea posted:

> 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.

And Gerald jumped with:

> Oh, but the CSP model does address the middle ground optimally ...

Just want to add my fourpennyworth :) ...

Hoare's original CACM paper on CSP was mostly about channels and synchronised
message passing.  Many still, probably therefore, associate CSP as being
solely concerned with non-shared-memory meassage-passing concurrency.  And
the "C" in "CSP" meaning "Communicating" reinforces that impression.

But the mid-80s revision in the CSP book presents a lower-level algebra,
still called CSP, that focusses on the more abstract notion of "event" and
multi-process synchronisation on "event"s.  CSP events provide the basis
for building all sorts of higher-level synchronisation mechanisms - not only
channel style communications, but also all varieties of locking mechanisms
that can be used to manage shared-memory concurrency.  KRoC occam and JCSP
offer examples of these - such as semaphores (used to manage shared channels
rather than data), barriers, buckets and CREW locks.  All these things are
well-defined on top of CSP basics and processes that interact with their
environments using them retain their WYSIWYG (and, hence, composeable)
semantics.

So, that's why CSP addresses shared-memory systems, distributed-memory
systems and the middle ground (natural hybrids).  Whether it does so
optimally is a matter of opinion, for which some evidence is available.

>From an understanding/design point of view, my experience is that processes
synchronising on these shared-memory primitives retain locally defined
semantics (WYSIWYG) and that concurrent system building with them still
coincides with my intuitive expectations.  When needed, we can fall back
on to formal CSP algebra to nail down precisely what we mean (and pick up
tools such as FDR and SPIN to assist).

>From a performance point of view, the KRoC barrier/bucket release operations
are unit time (i.e. regardless of the number of processes being released)
and that unit time will be around (guessing here for the latest 1.3.0 release)
200 nanoseconds on an 800 MHz PIII.  Other barrier/bucket/CREW syncs will have
similar overheads.

So, CSP has much to offer (and, maybe, lays claim to) the vast middle ground
of practical systems - those that are neither exclusively message-passing nor
shared-memory.  It also, of course, make claims on the extremes ;) ...

But, seriously, it does help us with shared-memory concurrency - there is
no conflict of paradigm.

Peter.