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 <[email protected]>
To: PyPy Developer Mailing List <[email protected]>
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
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
