[Python-Dev] Proposed PEP on concurrent programming support

PJ Eby pje at telecommunity.com
Wed Jan 4 06:07:27 CET 2012

On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <mwm at mired.org> wrote:

> STM is a relatively new technology being experimented with in newer
> languages, and in a number of 3rd party libraries (both Peak [#Peak]_
> and Kamaelia [#Kamaelia]_ provide STM facilities).

I don't know about Kamaelia, but PEAK's STM (part of the Trellis
event-driven library) is *not* an inter-thread concurrency solution: it's
actually used to sort out the order of events in a co-operative
multitasking scenario.  So, it should not be considered evidence for the
practicality of doing inter-thread co-ordination that way in pure Python.

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.

The disadvantage is that any code in a transaction must be safe to run
> multiple times.  This forbids any kind of I/O.

More precisely, code in a transaction must be *reversible*, so it doesn't
forbid any I/O that can be undone.  If you can seek backward in an input
file, for example, or delete queued output data, then it can still be done.
 Even I/O like re-drawing a screen can be made STM safe by making the
redraw occur after a transaction that reads and empties a buffer written by
other transactions.

> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120104/fc0df923/attachment.html>

More information about the Python-Dev mailing list