[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ALTs on inputs and outputs
> I understand that at one time the merits of ALTs on
> output channels as well as input channels in Occam
> was debated. CSP is even handed on the issue,
> can anyone explain why Occam isn't? -jc
You are opening up an *old* can of worms here! This used to come up
regularly at most transputer conferences in the 80s.
Barry and Gerald (thanks for digging out the references!) have said
most things. I'll just say:
o it *is just* a performance issue;
o that performance loss is particularly serious when a process doing
an ALTing input on one processor is up against a process doing an
ALTing output (on the same channel) on another processor - but it's
bad even if both processes are on the same processor;
o there is no problem if an ALTing output to a channel is up against
a committed (i.e. non-ALTing) input from the other process ... that
can be implemented in the same way (and as fast) as the normal ALT.
In "Five Essays on occam" (Marconi Avionics, 1984), I suggested a
syntax that would allow such things to be compile-time checked -
`positive' channels (that only allowed ALTing inputs) and `negative'
channels (that only allowed ALTing outputs). But, in fact, we
never found a pressing need to go to such trouble!
o we've only just (in part) proved the correctness of the JCSP ALT -
to be presented at CPA-2000. JCSP could easily add `negative'
channels as described above. But I don't fancy trying to do
the safe implementation of allowing both ends of a communication
to ALT over the same channel ... nor proving its correctness :-(
> HOWEVER, having said that I find I have a need for output guards in an ALT
> driving input guards in another ALT for a network routing switch design.
> So, I WILL be providing them in my occam to hardware compiler. It would be
> nice if JCSP could provide them too :-)
Oh, shucks! Guess we'd better speak at the conference!! Must fix up that
late bar ...