Ann: Stackless Limbo Dancing Works Fine!

[Fernando Pereira]

On 5/19/02 5:01 AM, "Christian Tismer" <tismer at tismer.com> wrote:

> Fernando Pereira wrote:
>> On 5/17/02 9:30 PM, in article
>> mailman.1021685435.8672.python-list at python.org, "Christian Tismer"
>> <tismer at tismer.com> wrote:
>> 
>>> - There isn't yet an ALT/PRI ALT construct like in OCCAM/ALEF/LIMBO.
>>> This is most sophisticated and very hard to implement correctly! I will
>>> try to find out how to do this the best way, during my stay at IronPort,
>>> from May 18th to May 29.
>> 
>> I was once involved in designing a channel facility with an ALT-equivalent,
>> and I found the following paper very useful:
>> 
>> Luca Cardelli. An implementation model of rendezvous communication. S.D.
>> Brookes, A.W. Roscoe and G. Winskel. Seminar on Concurrency, Carnegie-Mellon
>> University, Pittsburgh, PA, July 1984. Lecture Notes in Computer Science,
>> Vol. 197, Springer-Verlag, 1985, ISBN 3-540-15670-4. pp 449-457
>> <http://research.microsoft.com/Users/luca/Papers/Rendezvous.pdf>
> 
> Thank you very much for this link. I started to read it
> (but it is hard -- I'm deadly jet-lagged) and will try
> to get my brain around it tomorrow.
> 
> At first glance, I'm a bit stunned. Did you see my channel
> implementation? It is quite straight-forward and performs
> fine. But the principles appear to be upside down from
> those of the paper. My channels have a single queue of
> waiting tasks, and this queue is either for reading or
> writing.
> Currently I have a hard time to understand why there can
> be both an output and an input pool. My channels always
> fulfil whatever is possible, so only one pool would
> be populated at any time.
> I think I did quite something similar to their rendevouz
> operation.
I've not looked at this stuff since the mid 80s, but my recollection is that
the too pools are needed because task scheduling in Cardelli's scheme is
non-preemptive, independent of readiness to perform a communication on a
channel. That is, actual rendezvous may occur after both reading and writing
tasks are ready to communicate.
> 
> Interesting is that they don't even take processes as
> first-class objects. After introducin channels, I also
> found my tasklets less useful than before, and maybe
> they will survive only in a shadowy existance.
This was designed in the context of languages and formalisms like CSP and
Squeak (Cardelli and Pike's Squeak), in which tasks are not first-class
objects. In the introduction he says "processes are not denotable values".
> 
> Anyway, what I didn't grasp really yet is how to
> implement PAR as a multiple select on a group
> of channels.
I'm not sure of why you would need this, but maybe I've just been away from
this stuff too long. PAR just puts a bunch of tasks in the runnable pool.
When any of them wants to communicate, it suspends in the appropriate
channel queue waiting for a matching communication request (the matching
request may already be available, in which case the scheduler is free to do
the rendezvous and move the satisfied tasks to the runnable pool). In other
words, I don't understand why PAR would need to create a collection from the
channels used by the PARed tasks.
> Maybe I'm completely on the wrong track? I'd
> really be interested to read about your
> implementation.
I wrote a design document (which I may not have any longer, I'll look), but
it was never implemented because the resources were not available.
> thanks so much for your support, I really need to
> learn more, soon!
Welcome, and I hope Stackless prospers as it deserves.

-- F

PS. For a different but intriguing approach to communication in an OO
framework, check out Cardelli's recent paper on concurrency abstractions for
C#.

http://research.microsoft.com/Users/luca/Papers/Polyphony%20ECOOP.A4.pdf