[pypy-dev] The Work Plan Re: STM proposal funding

Andrew Francis andrewfr_ice at yahoo.com
Mon Mar 26 17:28:58 CEST 2012


Hi Armin:

I looked over the work plan. Cool! Some questions and comments.

1. rstm library:

I have looked at the rstm library. Wrote the "hello world" of transactional programming: the bank account example. . I also played with your STM stuff a few months ago.  A little while back, I started to go through your code to see what strategies you are using and the general architecture (hence the last batch of questions). I didn't get far but I want to resume real soon. If folks can tolerate scanned hand drawings (I am terrible with illustration software), I could post what I do. And the references I use will looking at the code ( i.e., "Software Transactional Memory 2nd by Tim Harris et el).  I don't know if this is helpful?


User Interface:

I am familar with the AME papers. AME literature seems to taper off. Have you tried talking to the various authors? Or get your hands on an implementation. For join papers, I talked to the Microsoft researcher involved and he was helpful.

To further understand what you are doing and get a feel for  STM would look like, I wanted to Python versions of the STAMP examples. Perhaps this would be a good way to craft an API in parallel with other work?


Half-Baked Ideas:

The reason I encountered STM literature is because I used stackless.py to prototype join patterns. One of these days, I'll finish that work and post it. After talking to the authors of "Scalable Join Patterns," I was referred to the work of John Reppy on Concurrent and Parallel ML.
Polyphonic C# has something that operates like channels. And Concurrent ML channels are very much like Stackless Python channels in the sense they are synchronous.

The tie-in to STM is both those implementations under the hood use a combination of STM and lock-free algorithms for efficient implementation. 

Now what makes this attractive for say,  a future Stackless Python is that message passing model usually lends itself well to a style where the programmer naturally knows how to partition their data amongst coroutines.

STM is used under the hood to implement the channels and other associated constructs. Hopefully this would 1) lead to a smaller transactional footprint. 2) Totally hide STM from the programmer. 3) Use an already existing API.

Thoughts?

Cheers,
Andrew



















________________________________
 From: Armin Rigo <arigo at tunes.org>
To: PyPy Developer Mailing List <pypy-dev at python.org> 
Sent: Monday, March 26, 2012 6:53 AM
Subject: [pypy-dev] STM proposal funding
 
Hi all,

For those of you who missed it: the proposal on Software Transactional
Memory is launched ("remove the GIL but give a better way to write
multi-threaded applications").  It is available at
http://pypy.org/tmdonate.html .

I plan to ask the PSF for some participation, following the push
towards doing so at the PyCon PSF meeting.  See
http://mail.python.org/pipermail/python-dev/2012-March/117680.html ,
"Funding from the Python Software Foundation".


A bientôt,

Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev at python.org
http://mail.python.org/mailman/listinfo/pypy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120326/737bbdec/attachment.html>


More information about the pypy-dev mailing list