Re: Synchronous Communication = Swap

[A E Lawrence <adrian.lawrence@xxxxxxxxxxxxx>]

M_Boosten wrote:
> 
> Synchronous communication is an essential concept with CSP.
> In case of synchronous communication, two processes synchronise.
> I.e., during a certain moment in time they are both engaged in
> communication.

No Marcel! CSP is much more general than this. I said as much at Kent.
:-)

1) CSP has no problem in modelling asynchronous events.
    If a process wishes to engage in an event and either the event
involves only the environment, or any partner processes are always
ready, then the event will occur immediately. That sort of eagerness in
built into the semantics.

2) A CSP event can involve any number of processes, not just two. The
channel concept is a sort of syntactic sugar overlaid on the underlying
model. Indeed, in most software applications we observe those
restrictions for very good reasons that you know. But in harware
compilation, for example, we definitely need and use more general
events. My stuff on HCSP depended on that more general view. The "tock"
events of a global clock in a synchronous digital circuit involve
typically several hundred processes in an FPGA: each active clb.

> During such a moment of sync, the two Processes can in principle
> EXCHANGE (BIDIRECTIONAL COMMUNICATION) data.  However, in Occam
> and most other CSP-based languages/libraries, data is only TRANSFERED
> (UNIDIRECTIONAL COMMUNICATION).

The exchange of data is outside the standard CSP model. In HCSP where I
allow
assignment to be a sort of CSP event, you might then perhaps regard that
as data exchange. Of course, you can regard the event itself as data in
some sense, even in pure standard CSP, but the point is that the CSP
model abstracts away from the precise nature of events. 

Please lets keep our notions simple, clean and precise. And particularly
not muddy the water about what CSP is. There is too much
misunderstanding about the nature of CSP around already.  What is going
on below is adding something on top of the CSP model. Which is fine: as
long as people don't think that CSP implies any particular accretions.

And you are exploiting the freedom that CSP gives to refine events, in
your case as a "swap". I like your idea of distinguishing the intiator
and observer| passive/active sides of the communication and decoupling
that from the direction, if any, of data transfer.



Adrian
-- 
Dr A E Lawrence (from home)