Process Inheritance and Reuse. Event inheritance too?

["Gordon Hutchison" <gordon_hutchison@xxxxxxxxxx>]

One of the great strengths of CSP is that there is no flow of information 
from any process without its involvement (hence the problems introduced by 
observing ready-sets etc?) and this relates to the problems of 
inter-thread shared state in the implementation. 
For me, one of the interesting things with CSP is mapping it to an 
implementation that is running on a weakly consistent SMP machine (most 
commercial servers that run unix tese days are of this type). 

In the CSP models I have seen to date there is a total ordering of the 
combined process event trace - though there may be many traces in a trace 
set with all the different possible interleavings off course. Many of the 
subtle problems we see when implementing the IBM JVM are to do with weak 
ordering where two threads observe things happening in different orders. 
When modelling this in CSP the obvious things is to put a limited 
re-ordering buffer that maps for example the "significant events" that 
James Corbett dicusses in his virtual coarsening stuff to the "fence 
instructions" of weak consistency models. 

However this chunk of process (that models the weak ordering 
characteristics of the environment and maps the CSP model of the world to 
my implementation environment) would ideally be easy to re-use. 

To this end I would seek a way to write a buffer process that processes 
events at an abstract level ("weakly-ordered" and "fence" "super-classes") 
and have my application events subclass these and pass cleanly through the 
buffer. I think it is possible to do some of this with M:N renaming that 
is supported in FDR but then there is loss of information in the buffer 
and I cannot turn my "fish into a shark again" on the other side again as 
can be done with an object references abstractly processed using a 
superclass name. (am I making sense? ) 

PS 
I am not a shovel advocate - as a JVM developer I have to admit to being a 
shovel MANUFACTURER 
....but in the shovel factory design shop we have some nice drawings of 
the shovel made with pencils :-) 








Lawrence Dickson <tjoccam@xxxxxxxxxxxxx>
11/02/2002 22:43

 
        To:     Gordon Hutchison/UK/IBM@IBMGB, P.H.Welch@xxxxxxxxx
        cc:     java-threads@xxxxxxxxx, occam-com@xxxxxxxxx
        Subject:        Re: OO&CSP

 

All,

I think anecdotes have their value (though in my case it wasn't an 
anecdote but two lived experiences, despite the unwillingness of some
OO advocates to believe it could be so) - but there is a point everyone
seems to be missing. THEY CAN EXIST SIDE BY SIDE - just like shovels and
saws - nobody assumes that the fact that saws work better than shovels
for some jobs implies shovels should be abolished.

Somebody, somewhere, somehow needs to face the fact that the OO paradigm
has limited usefulness and that parallel approaches (in both senses) will
enrich both education and real-world engineering. Admitting that it's
very time consuming to cut down a tree with a shovel should not be taken
as a threat by shovel advocates...

Larry Dickson

>From owner-occam-com-out@xxxxxxxxx Mon Feb 11 07:21:24 2002
To: gordon_hutchison@xxxxxxxxxx
Cc: java-threads@xxxxxxxxx, occam-com@xxxxxxxxx, P.H.Welch@xxxxxxxxx
Subject: Re: OO&CSP
From: "P.H.Welch" <P.H.Welch@xxxxxxxxx>
Date: Mon, 11 Feb 2002 15:21:04 +0000
Precedence: bulk


Hi Gordon,

> Is anyone else bored of all this process algebra vs OO debate. I am sure
> we are all well versed in both and their pros and cons.

The pros are well advertised but the cons are largely unacknowledged.
I guess many of us in University teaching are getting more uncomfortable
in pushing the pros on our students ... and this embarassment prompts
us to moan about it ... now and again ... just a little ... :)

But doing so just by anecdote doesn't progress things very much ... and
the CACM seems to be a big offender in this regard.  Whatever happened
to the CACM - it used to be *the* journal?

> 1) Dynamic object interactions: the need for dynamic alphabets and 
channel
> passing: pi&pict vav csp&occam

Absolutely!  The new (KRoC/Linux) occam will (soon) have dynamic channel
(and other event) creation, processes whose alphabets change over time
(as they enroll/resign from events), communicating channels and processes
over channels ... well some of this stuff will be a bit sooner than the
rest!  Of course, JCSP already has all of the above :) ... its security,
though, relies on the JCSP programmer playing the design patterns 
correctly.
For occam, the compiler will enforce correct play ... and the management
overheads will be around 500 times lighter.

occam has never been an absolute refelection of CSP.  It is both less than
it (e.g. no output guards, recursion etc.) and more than it (e.g. a block
structured name space, channel/event parametrisation of processes, PRI
choices and FAIR ones).  The "less than it" is very important for 
pragmatic
reasons - full blown CSP is too expensive to implement (probably).  The
"more than it" owes some dues to Milner's CCS (and pi-calculus) - 
especially
regarding name spaces!

> 4) MAXCHICKENS=3: Why do humans need to set the limits in CSP models, 
are
> there cases where FDR could work it out for a given subset of proofs?
> (Can you see that it is the tension between mathematical cleaness and 
ease
> of commercial applicability that is most interesting to me).

Yes - interesting problems here.  We built a CSP model of Java's monitor
primitives (synchronized/wait/notify/notifyAll) and then were able to use
the FDR model checker to verify the correctness of JCSP (and CTJ) channels
and the JCSP ALT.  At least, on the last item, we were able to verify the
correctness of a 2-way ALT over channel input guards - which was a great
relief given the difficulties in constructing and understanding the logic
of monitor implementations.

Now, we could have extended our model to verify (hopefully) the 
correctness
of a 3-way ALT.  But we haven't.  What we really want to do is verify the
correctness of the n-way ALT, for all n >= 0.  Humm ...

Another wish: I'd like a CSP-like algebra that is a consistent complete
subset of CSP that reflects only the occam-implemented (i.e. unit time
complexity) primitives.  I'd like a model checker specific for that subset
and semantics preserving transformer tools.  Then I'd like that extended
to deal with PRI ALTs, FAIR ALTs, timeout and SKIP guards (and the model
checkers/transformers upgraded to match).  Plus the dynamic alphabet stuff
we have in JCSP and (soon) occam.  Plus SHARED channels.

Plus channels of channel-ends and channels of processes.  And an event
interface algebra to allow me to abstract the essential information as
to what a process does and how it engages with its environment to do it
(need to combine this with Z specifications) ...  and will allow me decent
flexibility to derive processes from already existing processes (in a way
that works *much* better than OO inheritance).

And, then, we can have breakfast!

Peter.