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.