[Stackless] Dining Philosophers with Join Patterns and Stackless.py

[Andrew Francis]

Hi Richard:

Thanks for the input. Yahoo is a pain in the butt when it comes to replying.


>First the superficial stuff.  Dining philosophers is boring and
>academic.  It wasn't interesting to me in university, it isn't now,
>and its lack of usefulness hides the usefulness of whatever implements
>it. 

Dining philosophers is academic. However I hardly think it is boring. Dining philosophers like so many computer problems are contrived on purpose. However the techniques to solve them are extremely applicable. On a side note, I am going through "The Little Book of Semaphores" and looking at the examples. 

As for join patterns. For me join patterns hint to a more clutter-free and declarative style of concurrency. At its heart is the ability to atomically perform transactions. 

I am still learning.....

>Next your join patterns and select.  When I read the code I don't
>understand it.  I think that there has to be a simpler interface than
>arcane terms like "joinPattern", "JoinReceiveChanop" and
>"receiveCase".  

As I stated in the original post, I am still working on the API. When complete, you will not see JoinReceiveChanop: it is an implementation detail. Nor will you see select(). This is again an interesting implementation detail. I extended the algorithms of Pike/Cox to support a limited form of join patterns. So in a scene, the same algorithm should work in Go (albeit with a big performance hit).  What the example will eventually look more like:

def thinker(name, thinking, left, right):
    while True:
       waitTime = random.randint(thinking[0], thinking[1])
       print name, "thinking for ", waitTime, "time units"
       tick(waitTime)
       print name, "ready to eat"
       result = stackless.join().addPattern([left,right]).do()
       for p in result:
           print p.value, " relinquished chopstick ", p.channel.label

Does this make more sense?

Again, I am working on the API. Heck I am still working on the implementation. Amongst other things I need to write more tests to ensure stuff is really working.

>However, I think I would need that practical example
>where this is useful before I could suggest something better. 

I will work on more practical examples. I can show how to use join patterns to impose a logical ordering on tasklets. Or how to implement the foreach statement in WS-BPEL. Or to do M out of N choices: i.e., send requests for quotes to ten contractors (imagine these being RESTful web services) and block until one gets   a quorum of seven... or a timeout. Or replace contractor web services with sensor interfaces, say something a Green Goose tagged internet-of-things object would generate.  

That said, I am really interested in how much of a performance hit does the Stackless.py prototype take implementing join and select. I don't think the extra power is worthwhile to make it a general feature if it imposes a big performance cost on simple things. Quite frankly, I think a stackless with select and join will be in a custom tailored module running under PyPy. Once genlets are working, this would be the way to go.

>expect that the only way to make a straightforward and easy to use
>interface would be if the language facilitated it, and as you are
>using pypy I believe, that's actually a possibility.

Originally this was the opinion of my friend Kevin (whom immensely helped me with select) and myself. However after actually writing examples, I had come not to share this opinion. Moreover I regularly read the Go mailing list. I have seen how difficult it is to write examples with a dynamic number of channels with a fixed select language feature. And to wait on multiple goroutines, mutexes are used.  

On the other hand,  I have seen the object based work that Microsoft has done with Polyphonic C# and this seems to be a model more suited for Stackless. 

As you have pointed out, the key is to write more practical examples. Also if people use the experimental features then we can craft a better API. I will be the first to admit that without language support, the API can be tricky. So let me do some more work and get a new implementation into the stackless repository.

>Anyway hope this is of some help,

Yes it is!

Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20110825/0bc5efe5/attachment.html>