My understanding is that due to the Global Interpreter Lock (GIL) in cPython, only one thread can ever be executed at any one time. Does this or does this not automatically protected against race conditions, such as the lost update problem?
Asked
Active
Viewed 3,298 times
18
-
Only one thread can be executing python bytecode. You shouldn't rely on this and assume race conditions are impossible. – Wooble May 25 '14 at 12:16
-
So you can still have an interleaving of threads which would cause a lost update? – May 25 '14 at 12:17
-
2Sure. 2 threads executing python instructions won't execute at the exact same time on different cores (which is why threading generally won't help performance), but it's not like the interpreter picks one thread to run until it exits before executing the next. That would be... madness. – Wooble May 25 '14 at 12:19
-
While the question implies that threading-related race condition are the scope of discussion, it's not really spelled out anywhere. Obviously the GIL does not help at all for interprocess race conditions (two instances of the same code running on different CPUs, etc). – tripleee May 25 '14 at 12:40
1 Answers
30
Due to the GIL, there is only ever one thread per process active to execute Python bytecode; the bytecode evaluation loop is protected by it.
The lock is released every sys.getswitchinterval() seconds, at which point a thread switch can take place. This means that for Python code, a thread switch can still take place, but only between byte code instructions. Any code that relies on thread safety needs to take this into account. Actions that can be done in one bytecode can be thread safe, everything else is not.
Even a single byte code instruction can trigger other Python code; for example the line object[index] can trigger a __getitem__ call on a custom class, implemented itself in Python. Thus a single BINARY_SUBSCR opcode is not necessarily thread safe, depending on the object type.
Martijn Pieters
- 1,048,767
- 296
- 4,058
- 3,343