<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi Armin:<br></span></div><div><br></div> <div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"> <div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight: bold;">From:</span></b> Armin Rigo <arigo@tunes.org><br> <b><span style="font-weight: bold;">To:</span></b> Andrew Francis <andrewfr_ice@yahoo.com> <br><b><span style="font-weight: bold;">Cc:</span></b> PyPy Developer Mailing List <pypy-dev@python.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Monday, January 9, 2012 8:03 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [pypy-dev] STM<br> </font> <br>
Hi Andrew,<br><br>On Sun, Jan 8, 2012 at 21:24, Andrew Francis <<a ymailto="mailto:andrewfr_ice@yahoo.com" href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>> wrote:<br><br>AF> A silly question? What is the paper you are discussing?<br><br>>The Problem with Threads, Edward A. Lee, EECS 2006.<br><br>Thanks!<br><br>AF> Perhaps this is off-topic, in non-trivial stackless programme using<br>AF> cooperative scheduling, unless you explicitly impose a logical ordering, it is difficult to predict<br>AF> when a particular tasklet will run. The round-robin doesn't mean much.<br><br>>Ok, so basically no real Stackless program relies on a particular order anyway. This is in <br>>line with what I expected.<br><br>Yes.<br><br>Even taking into consideration stuff like channel preferences, I think it is difficult to second guess<br>the scheduler based in even a moderately complex application. Where you really see
the philosophy of<br>scheduler as an opaque entity is in the Bell Labs family of languages (Go included). The reasons I<br>mention Go is that they are tackling the multiple CPU issue (albeit differently from what is proposed<br>here) and it and Stackless share family resemblances. <br><br>Now what I believe is a bigger issue is rationalising the relationship between scheduler(s), <br>tasklets, and threads. Again, maybe STM solutions can be tested with an inexpensive <br>prototype.<br><br>AF> If I understand what you are proposing, the problem I see with yielding in<br>AF> the coarse-grained tasklet-as-transaction, is that you probably need more<br>AF> machinery to ensure ACID properties, since you are now getting thread<br>AF> interweaving and potential race conditions.<br><br>>Yes, and this machinery is exactly what STM libraries offer. Given<br>>that you have multiple transactions that can *mostly* occur
in<br>>parallel, STM ensures that in *all* cases, it will look like the<br>>transactions have been run serially, while actually performing them in<br>>parallel under the hood.<br><br>A rich STM library like rstm offers a variety of techniques for making this happen. <br>On the other hand, the Transactional specification has very specific (and maybe more<br>conservative) ways of achieving serialisation and race-free programmes. My gut feeling <br>is that it is difficult to get a one size fits all solution. Maybe an interim solution is to get<br>to a stage where one has a prototype that allows for pluggable STM solutions? A "try before you<br>buy"strategy.<br><br>I am also not clear on whether a STM interface exposed to a Python programmer will be <br>the same as STM (and other techniques, say lock-free data structures) used internally to <br>support multiple processors.<br><br>I think this is an exciting time for stuff like
PyPy/Stackless!<br><br>Cheers,<br>Andrew<br><br><br><br> </div> </div> </div></body></html>