Re: Loosing abstraction due to non-alting channels

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

Hi everyone,

I've been meaning to reply but other things keep pre-empting my head.
More on priorities, pre-emption, priority inheritance, missed deadlines
and the Mars Pathfinder software later ...

Marcel was worried that JCSP makes us declare in a process' interface
that we intend to ALT on a channel input and that this implies a loss
of abstraction:

> In JCSP details about the implementation of the process
> need to be known to use processes: some degree of abstraction
> and composability is lost.

I want to argue that the reverse is actually the case ;-) ...

CSP/occam channels provide a very clean - but very low-level - abstraction.
If all we declare to the user of a process is its channel interface, users
can plug-and-play with it in any way that it will fit into a network.  But
some of the resulting topologies will be dangerous (e.g. deadlock prone).

A decent abstraction for a process requires three things:

  o how it plugs into its environment (e.g. a channel interface);
  o how it is prepared to synchronise with its environment (e.g. promise
    service on some channels, demand service from others, refuse to service
    some channels unless in a certain state, accept input and/or generate
    output on certain channels in parallel etc.);
  o what outputs it generates and how they relate to inputs.

CSP allows us to make mathematically precise the first two of the above bullets
and Z, for example, addresses the third.  That's an ideal to strive for for
every process ...

Just giving the channel interface is, I contend, not enough - it only targets
the first of those bullets.  Suppose we have a process with an input/output
pair of channels that it uses for client-server transactions.  We need to know
whether it uses those channels as a *client* (i.e. it may spontaenously output
a service request and then commit to input a reply) or as a *server* (i.e. it
never does anything spontaenously, but waits on the input channel (possibly
ALTing over other service request channels) and only outputs in response to
an input.

Such information provides a much richer abstraction for the process.  It's
not implementation detail - it's behavioural detail that is crucial for the
user to know ... a necessary part of the abstraction.  The graphical occam
Design Tool (oDT) we built way back does enable users to make such abstractions
and acted upon them by checking that the networks built from such processes
followed associated design patterns for which we had formal proofs that the
results would be deadlock/livelock/starvation-free.

These techniques are not a complete answer to the need for a formal CSP-like
specification of how a process behaves with its environment, but it is a decent
step in that direction that would be easy for non-mathematicians to use.

JCSP does not go that far - but I'd like to explore how much of that could
be supported within the confines of Java (i.e. before resorting to tools
other than the compiler).  Meanwhile, it goes a *little* way by asking us
to say, at least, that a process will be ALTing on a channel - it gives a clue
that some kind of servicing is happening.  When describing an occam example
process to students, I always do that at least, albiet informally.  In occam,
we can't make that point in a PROC declaration - in Java/JCSP, we can.  So,
that's why I think this *helps* create a richer abstraction than that given
by the channel alone.

I'll be posting some more on this ... ;-) ...

Peter.