Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!icdoc!sot-ecs!dbc
From: dbc@ecs.soton.ac.uk (Bryan Carpenter)
Newsgroups: comp.sys.transputer
Subject: Re: producers and consumers
Message-ID: <6679@ecs.soton.ac.uk>
Date: 11 Feb 91 16:11:22 GMT
References: <1461.9101292134@prg.oxford.ac.uk> <ZENITH.91Feb5183149@isatis.isatis.ensmp.fr> <1991Feb6.122949.8210@rodan.acs.syr.edu> <6591@ecs.soton.ac.uk> <1991Feb8.121349.17501@rodan.acs.syr.edu>
Organization: University of Southampton, UK
Lines: 86

In <1991Feb8.121349.17501@rodan.acs.syr.edu> greeny@wotan.top.cis.syr.edu (Jonathan Greenfield) writes:

>In article <6591@ecs.soton.ac.uk> igl@ecs.soton.ac.uk (Ian Glendinning) writes:

>>> (Hoare's definition of parallel composition is inadequate.)
>>
>>Please explain.  Why is it inadequate?

>...

>>>(Note that, ignoring the procedural/functional differences, the main 
>>>conceptual difference between CSP and occam involves the action of parallel 
>>>composition.)
>>
>>Again, please explain.  I always thought they were the same.

>If you are familiar with occam, it should be clear that the definition of
>the parallel composition operator (PAR) is quite different.  Consider two
>occam processes,

>  SEQ
>    <interact in event>
>    x := 1

>and

>  SEQ
>    <interact in event>
>    y := 2

>(Let us use an <event>, without worrying about channels, communication, and 
>other concepts that are not relevant to this discussion 
>of parallel composition.)

>Now consider the parallel composition of these:

>  PAR
>    SEQ
>      <interact in event>
>      x := 1
>    SEQ
>      <interact in event>
>      y := 2

>which is equivalent to the occam process:

>  x, y := 1, 2

>because the <event> actually takes place.  It is an internal event that
>is invisible outside of the scope of the PAR operator.  One may prefer
>to view this as:

>  SEQ
>    <event takes place>
>    x, y := 1, 2

>Notably, the parallel composition is NOT equivalent to:

>  SEQ
>    <interact in event>
>    x, y := 1, 2

>which is what one would expect based upon Hoare's notion of parallel
>composition.

>Fundamentally, when two processes share an event in occam, the event takes
>place.  In CSP, it does not.

I don't see what you're getting at really.  The (communication)
event in occam surely does take place.  In occam though
particular events (the only ones supported---communications)
can only be in the alphabets of *two* processes, so their occurence
will only directly effect these two processes.

CSP, of course, has the same ability to limit particular events to
the alphabets of a subset of all processes---I don't see that events are
necessarily all "broadcast" in the way you seem to suggest.

The difference seems to have more to do with how many processes can
share an event (in their alphabets), rather than the nature
of the concurrency.


>Jonathan

Bryan