[Python-Dev] Proposed PEP on concurrent programming support (original) (raw)

Mike Meyer mwm at mired.org
Thu Jan 12 01:01:44 CET 2012

On Wed, 4 Jan 2012 00:07:27 -0500 PJ Eby <pje at telecommunity.com> wrote:

On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <mwm at mired.org> wrote: > A suite is marked > as a transaction, and then when an unlocked object is modified, > instead of indicating an error, a locked copy of it is created to be > used through the rest of the transaction. If any of the originals > are modified during the execution of the suite, the suite is rerun > from the beginning. If it completes, the locked copies are copied > back to the originals in an atomic manner. I'm not sure if "locked" is really the right word here. A private copy isn't "locked" because it's not shared.

Do you have a suggestion for a better word? Maybe the "safe" state used elsewhere?

> For > instance, combining STM with explicit locking would allow explicit > locking when IO was required, I don't think this idea makes any sense, since STM's don't really "lock", and to control I/O in an STM system you just STM-ize the queues. (Generally speaking.)

I thought about that. I couldn't convince myself that STM by itself sufficient. If you need to make irreversible changes to the state of an object, you can't use STM, so what do you use? Can every such situation be handled by creating "safe" values then using an STM to update them?

   <mike

More information about the Python-Dev mailing list