[monopede]

As I understand this, this wouldn't automatically protect you from race conditions. If you have a shared variable x then a statement like

  x += 5

may be fine depending on whether it is implemented as a single bytecode instruction or not. However, more complicated updates are still subject to races:

  x = somefunction(x)

It is only safe if you use:

  with thread.atomic:  x = somefunction(x)

Having a serialisation doesn't mean it's the right serialisation.

That said, the fundamental problem is shared mutable state, and I don't see an easy way around that in Python. In that sense, this is probably easiest to work with.

[apendleton]

Right, this is no different than it would be programming on current Python with the GIL. There are two different levels of locking in current Python implementations: locks within the implementation of the interpreter (the GIL for cpython and current pypy, or all the micro-locks in Jythin), and the locks accessible from the Python environment by Python programmers (e.g., the locks in the threading module: http://docs.python.org/library/threading.html#lock-objects ). The pypy STM project attempts to replace the first set to allow for simultaneous multi-core use while making it seem to the programmer like the GIL is still there, but if the programmer needs things like a specific execution order, it will need to managed by hand, the same way it always has.