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

[Christian Tismer]

Just a quick note, as I'm moving right now and inactive for another month, and had no time to look at the code at all:

The survival of an interface goes with its simplicity and usability. If it fails that, then Stackless is not improved: having a hard-to-understand feature or no feature at all makes little difference. The academic achievement is fine for the scientist, but that will not be enough reason to add the feature. 

Richard had a problem to understand the proposed interface, being much more that an experienced user. I would take that as a serious indicator that the interface must change its whole approach. There need to be a direct, simple as possible way to see the benefit of the feature, and how to use it in the most common scenarios. Every more detailed sub-interface may come after that, after the hurdle of making the user interested is taken. 

Just my 2 cents, after I made this mistake myself way too often. 

Cheers - chris

Sent from my iPhone

On Aug 25, 2011, at 18:08, Andrew Francis <andrewfr_ice at yahoo.com> wrote:

> 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/20110826/5c69bba1/attachment-0001.html>