multiway sync guards (AltingBarriers)

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

Hi,

Should have announced this before Christmas ...

I've put up an *interim* new JCSP release containing the AltingBarriers
plus lots of documentation and demo programs (there's a game!).  They
enable almost any CSP equations to be directly captured in JCSP.  Prior
to this, external choice was limited to guards that were channel inputs,
call channel accepts, timeouts and skips.  CSP people, though, seem to
make extensive use of choice between multiway synchronisations.  JCSP
has always had committed multiway synchronisation (Barriers) - now, it
has a version we can use as ALT guards, :).

This new release is a development of our core JCSP release (rc7) and is
in the usual place:

  http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Follow the README link on the above page to see the updates from rc4 -
the last public release!  The main changes are the handling of spurious
wakeups, :(, optional instrumentiation to log them (still never seen any!)
and a version of barrier synchronisation (i.e. CSP multiway events) that
can be used as Guards in Alternatives, :).  This latter uses a new and
fast algorithm for resolving choice between multiway synchronisations -
i.e. does not use a 2-phse commit.

Documentation is on-line.  The stuff on Altingbarriers is at:

  http://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp1-0-rc7/jcsp-docs/jcsp/lang/Alt
ingBarrier.html

which has lots of demo Java code (nicely 2-space indented throughout, :)).
The game is in jcsp-demos/alting-barriers/ - see AltingBarrierGadget6 ...
it needs a little development ... there's no way to win right now ...

The release is called "interim" above because, hopefully, this will be
the *last* release of our core version of JCSP.

We have been working hard on integrating the JCSP 1.0-rc5 core with
Quickstone's version - that's done (thanks to Neil Brown and Kevin Chalmers).
The core rc6/7 stuff has to be added and there's another implementation
re-arrangement to happen before we release the fully integrated stuff -
but soon!!  :)

The main difference between Quickstone's JCSP core and our original is
the separation of channel "ends" from channels (as in occam-pi).  This
has lots of benefit ... it's not just something for distributed channels.
The integrated version uses Quickstone's mechanism.

The "ends" are got from channels by the in/out() methods, about whose names
Anne was complaining.  In our minds, "in" corresponds to "input" which
corresponds to the input process in CSP, represented by "?".  That is,
"in" gets you the end of the channel on which a process performs input
(i.e. reading).  It's *not* the end of the channel on which messages
are pumped in - that's the "out" (or "output") end.  As Larry said, we
are *process* oriented.  Terms are chosen from the point of view of
the (active) processes - not the (passive) channels.

The AltingBarrier is just a front-end to a real alting barrier structure,
which is hidden from the user.  Each process must acquire its own front-end
to each alting barrier it uses ... in the same way that a process must
acquire an input-end (reading-end) or output-end (writing-end) to a channel
in the Quickstone version.

The current JCSP Barrier (non-alting) does not have front-ends.  Having
them would enable tighter run-time security (e.g. against a process using
it when not enrolled), so I wonder about that.  However, having to setup and
distribute AltingBarrier front-ends is a little tricky (see the documentation)
... although this is a static operation done once before use.  The JCSP
AltingBarrier needs setting up through front-ends for technical reasons
other than increased security (which it does have).

Peter.