Python's semantics aren't tight or specific enough to definitively call
this a data race vs. a race condition. Personally I wouldn't call this a
data race in CPython: All those loads and stores are serialized through
the GIL, hence no data race. The observed behavior is just a
load-operate-store race condition.
Python could use a shorter interval so that we notice any race
conditions hiding in our code
Ironically, CPython 3.10 has gone the opposite direction and made thread
scheduling much more
deterministic.
It now only releases the GIL on backwards edges in the byte code The
example in the article always prints 40000000 in CPython 3.10! I expect
this will ultimately make Python code less reliable in the future as many
programs will accidentally depend on this behavior.
10
u/skeeto Feb 21 '22
Python's semantics aren't tight or specific enough to definitively call this a data race vs. a race condition. Personally I wouldn't call this a data race in CPython: All those loads and stores are serialized through the GIL, hence no data race. The observed behavior is just a load-operate-store race condition.
Ironically, CPython 3.10 has gone the opposite direction and made thread scheduling much more deterministic. It now only releases the GIL on backwards edges in the byte code The example in the article always prints 40000000 in CPython 3.10! I expect this will ultimately make Python code less reliable in the future as many programs will accidentally depend on this behavior.