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