[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: many-to-one channel
Thanks, Peter. I'm poking at the idea of an extension of occam that is
locally static but quasi-dynamic in that things can be added on (or
removed) when communication is in a quiescent state. The defining
characteristic is lack of fragmentation - so there is always one
"wild" C-like heritage that acts like an OS owning "outer" stuff, but
everything of interest happens in "tame" processes that are spawned by
the wild heritage in a nested fashion, and act like straight (non-
dynamic) occam after that. But resources that were declared at an
overarching parent level can be "loaned" between children. I'm
wondering if the Transterpreter bytecode supports a superset of this.
To permit a process analogue of a driver, it needs many-to-one
(definitely NOT one-to-many or many-to-many) channels and the ability
to "loan" a channel to the driver so that the driver can report
completion and/or send read data. (Is this a "mobile channel"? I mean
for ownership to be clear at all times and the loaned channel is
restored to the user process at the end of the IO operation.)
Does Transterpreter byte code support these constructs? Is there any
document defining the Transterpreter bytecode instructions, or better
yet defining the difference between Transterpreter bytecode and that
of the "Compiler Writer's Guide" to Transputer instructions?
By the way, the summary of the many-to-one state machine that I posted
October 18 was incomplete. It forgot to mention the abandonment ((R,N)
to (N,N)) of its channel position by an ALT loser.
On Oct 19, 2008, at 12:03 PM, P.H.Welch wrote:
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
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
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