Ann: Stackless Limbo Dancing Works Fine!

Fernando Pereira pereira at cis.upenn.edu
Tue May 21 16:16:19 EDT 2002


On 5/21/02 12:07 AM, in article ueji35ihipuee3 at corp.supernews.com, "Andrew
Henshaw" <andrew.henshaw at mail.com> wrote:
> An Occam channel is very simple and was implemented efficiently in the
> Transputer's microcode.  I suspect that having only a single transmitting
> process and a single receiving process simplifies that task.  As I said
> before, I believe that this holds for CSP also.
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.
>  The main difference
> between CSP and Occam channels is the ability of an ALT-type construct to
> know whether a receiving process on the other end of a channel is ready to
> receive (called an output guard, IIRC).  In Occam, if you're a transmitting
> process, you can't simply check whether a receiver is ready to go; you have
> to commit to your send and then the communication either completes or you
> block.
The critical difference is not any ALT-type construct, but the fact that the
same channel can be shared among multiple concurrent readers and writers.

BTW, you might find useful some of the materials on JCSP

http://www.cs.ukc.ac.uk/projects/ofa/jcsp/

-- F




More information about the Python-list mailing list