[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: many-to-one channel



Hi Larry,

Sorry - been away ...

> Can you point me to a "standard" definition of a many-output-to-one- 
> input channel? The subject came up in a discussion I am having with  
> the Stackless Python people. I cobbled up a two-word version but  
> cannot remember if it was the standard way. The input needs to be able  
> to do ALTs, which I (subject to correction) don't think the many-to- 
> many can do.

These have been around a long time in occam-pi (SHARED channel-ends)
and JCSP (Any2One channels).  Indeed, both support (fast) ALTing at
the input-end.  SHARED channel-input (occam-pi) and XXX2Any (JCSP)
are also supported but, as you say, we can't ALT on those inputs.

The informal semantics are that any process holding the shared (many)
end of a channel may attempt to use it at any time.  As Alistair ays,
the formal CSP semantics has those processes *interleaving* for their
use of that channel-end.  Any *one* of them at a time synchronises
with a process at the other end (a unique receiver, in the case of
many-to-one).

The kroc runtime refines the CSP formal interleaving by FIFO queuing
processes competing for a shared channel-end.  In CSP, the choice
between processes competing to use a shared event on which they are
interleaving is *arbitrary*.

JCSP leaves you at the mercy of the JVM to resolve this choice.
The competing processes compete for a simple monitor lock: most
JVMs will queue them ... but that's not mandatory and some will
stack them!

Cheers,

Peter.