6 ms·
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 fin
by monopede 14y ago
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 14y agoRight, 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 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.