(original) (raw)

On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <mwm@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.

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.)