Ann: Stackless Limbo Dancing Works Fine!

[Andy Rabagliati]

According to Andrew Henshaw  <andrew.henshaw at mail.com>:
> Fernando Pereira wrote:
> 
> > On 5/23/02 11:31 PM, in article uerd0l9d54dac9 at corp.supernews.com, "Andrew
> > Henshaw" <andrew.henshaw at mail.com> wrote:
> > 
> >> Fernando Pereira wrote:
> >>> I can't find my CSP book, but from memory I don't think this is correct.
> >>> Through || (PAR), it is possible for several concurrent processes to
> >>> attempt to read or to write on the same channel. Then the channel
> >>> implementation needs a queue to hold all the blocked processes until a
> >>> complementary event occurs, at which point one of the pending requests
> >>> is matched to the event and the blocked process becomes runable.

My experience has been exclusively with occam, on transputers and
other hardware, So I can only comment on the practicality of these
conventions.

I would have a problem if the possibly arbitrary order the sending
processes arrived at their output statements, would then determine the
order the inputting process had to serve them. Smells of deadlock to me.
- I would very much prefer the occam ALT to an imposed order.


> >> "We shall observe the convention that channels are used for
> >> communication in only one direction and between only two processes.
> >> A channel which is used only for output by a process will be called
> >> an output channel of that process; and one used only for input will
> >> be called an input channel.

> Certainly, as I demonstrated with the Occam examples, you can build
> higher-level constructs that achieve the effect; but, the channel
> primitive itself does not have that characteristic.

Indeed , I had (have ..) an arsenal of these - FIFOs, multiplexers,
tiny little processes little more than an ALT statement wrapped in a
WHILE loop.

The occam compiler impoved vastly in its useability when automated
checking of channel usage per the 'shall ..' directive above was
included. Without that checking, complex programs became a nightmare. I
cannot say if this was an occam 'feature' or a CSP feature, but I would
guess it applies to both.

Cheers,   Andy!