Question about the STM module and RSTM
Hi Folks: I understand that the STM module is still in its infancy. And subject to change at a moment's notice. I enjoy reading the transactional memory related blog posts. Over the weekend, I have been looking at the stm and transactionModule and the C++ based rstm. I haven't written an C++ based programme yet but that will change soon. If the stm library progresses a bit more, I would like to try writing Python versions of some of the STAMP examples. Until then, I am trying understand the relationship between stm and rstm. It does not seem that stm is simply a wrapper for rstm (a lot of work went into stm!). There are things in rstm that I see such as the ability to configure parameters, set policies and to get diagnostics (i.e., number of aborts). Are there plans to do this with the stm module? Cheers, Andrew
Hi, On Mon, Jan 30, 2012 at 21:20, Andrew Francis <andrewfr_ice@yahoo.com> wrote:
You wouldn't be able to write pure Python versions of classical STM examples, because the "transaction" module works at a level different from most STM implementations. You can try to write RPython versions of them, just for fun, but they may break at a moment's notice. In PyPy, we look at STM like we would look at the GC. It may be replaced in a week by a different one, but for the "end user" writing pure Python code, it essentially doesn't make a difference. That's why we have no plan at all to let the user access all the details of the STM library. Even the fact that STM is used is almost an implementation detail, which has just a few visible consequences (similar to how the very old versions of Python had a GC based on refcounting alone, which didn't free loops). A bientôt, Armin.
Hi Armin: ________________________________ From: Armin Rigo <arigo@tunes.org> To: Andrew Francis <andrewfr_ice@yahoo.com> Cc: Py Py Developer Mailing List <pypy-dev@python.org> Sent: Monday, January 30, 2012 3:46 PM Subject: Re: [pypy-dev] Question about the STM module and RSTM
I would still be interested in writing RPython and Stackless versions.
Perhaps one reason you would want to exposure the STM module is for other language implementations that could use STM? An example. My interest in Stackless Python and PyPy (via stackless.py) came out of wanting to develop a WS-BPEL processor. My initial approach was to write a WS-BPEL to Python pre-processor. PyPy would allow me to write a WS-BPEL processor in ways I couldn't imagine a few years ago. I'm on the fence about WS-BPEL these days. As for your approach. Like a lot of people on the blog, it is not the way I understood STM to work. For me this is because Haskell is the only approach I've seen. Reading papers has exposed me to more ideas. I have been reading the text "Transactional Memory, 2nd (2010)" by Harris, Larus, and Rajawar. In one of the sections, they describe an approach called "Transactions Everywhere." Assumption is that transactions are the norm, not the exception. So atomicity is the default. Connected to that is TM based on Automatic Mutual Exclusion (or AME). Roughly, AME is a cooperative multi-threading system that is build over STM. Perhaps this is helpful, you can read the paper "Automatic Mutual Exclusion" (http://research.microsoft.com/en-us/projects/ame/automutex-hotos.pdf) or look at other papers at the site. Salut, Andrew
Hi, On Mon, Jan 30, 2012 at 21:20, Andrew Francis <andrewfr_ice@yahoo.com> wrote:
You wouldn't be able to write pure Python versions of classical STM examples, because the "transaction" module works at a level different from most STM implementations. You can try to write RPython versions of them, just for fun, but they may break at a moment's notice. In PyPy, we look at STM like we would look at the GC. It may be replaced in a week by a different one, but for the "end user" writing pure Python code, it essentially doesn't make a difference. That's why we have no plan at all to let the user access all the details of the STM library. Even the fact that STM is used is almost an implementation detail, which has just a few visible consequences (similar to how the very old versions of Python had a GC based on refcounting alone, which didn't free loops). A bientôt, Armin.
Hi Armin: ________________________________ From: Armin Rigo <arigo@tunes.org> To: Andrew Francis <andrewfr_ice@yahoo.com> Cc: Py Py Developer Mailing List <pypy-dev@python.org> Sent: Monday, January 30, 2012 3:46 PM Subject: Re: [pypy-dev] Question about the STM module and RSTM
I would still be interested in writing RPython and Stackless versions.
Perhaps one reason you would want to exposure the STM module is for other language implementations that could use STM? An example. My interest in Stackless Python and PyPy (via stackless.py) came out of wanting to develop a WS-BPEL processor. My initial approach was to write a WS-BPEL to Python pre-processor. PyPy would allow me to write a WS-BPEL processor in ways I couldn't imagine a few years ago. I'm on the fence about WS-BPEL these days. As for your approach. Like a lot of people on the blog, it is not the way I understood STM to work. For me this is because Haskell is the only approach I've seen. Reading papers has exposed me to more ideas. I have been reading the text "Transactional Memory, 2nd (2010)" by Harris, Larus, and Rajawar. In one of the sections, they describe an approach called "Transactions Everywhere." Assumption is that transactions are the norm, not the exception. So atomicity is the default. Connected to that is TM based on Automatic Mutual Exclusion (or AME). Roughly, AME is a cooperative multi-threading system that is build over STM. Perhaps this is helpful, you can read the paper "Automatic Mutual Exclusion" (http://research.microsoft.com/en-us/projects/ame/automutex-hotos.pdf) or look at other papers at the site. Salut, Andrew
participants (2)
-
Andrew Francis -
Armin Rigo