I have said something wrong in my previous post. I think the correction is very relevant to this discussion, so I’ll try to explain my mistake as clearly as I can.
What was wrong
I said that in this example program, thread 2 will see the write x = 2 in all memory models:
That is not true. In fact, a very similar example is given in Java’s memory model specification, stating that the write may never be read by thread 2. Let me report the Java code from the example in the specification (section 3.1):
class LoopThatMayNeverEnd {
boolean done = false;
void work() {
while (!done) {
// do work
}
}
void stopWork() {
done = true;
}
}
According to the Java MM, and assuming that one thread is executing the work() method and a different thread eventually calls the stopWork() method, it is entirely possible that the loop never ends. (Note that the MM does not specify whether it will end.) I think it’s worth investigating the reason why the Java specification allows for this.
The reason why the work() thread may never exit the loop is that a Java compiler can optimize the loop to completely eliminate the read on the variable done. After all, the thread that is performing the loop never writes into the variable, so why bother checking it? The Java compiler simply doesn’t know that done is a shared variable.
The significance for Python
At this point, it’s important to mention that CPython (the implementation of the language that people commonly use) does not currently host a compiler that does this kind of optimization. Therefore, this sort of problem never arises in Python code. Let’s look at the Python version of the example above:
done = False
def work():
while not done:
# do work
def stopWork():
done = True
Even though the current JIT compiler will not eliminate the while not done check, it is not inconceivable that one day it might, for the same reasons that Java compilers do this kind of optimizations. Hence, if we want to seriously address the main problem of this thread, we must answer two questions:
- is this Python code safe now? Yes.
- will this Python code be safe in the future? Maybe.
If current proposals like Shannon’s PEP 805 do go forward, then I don’t see why the above code should become unsafe in the future. (And it’s very desirable that it stays safe, so I reckon there’s a very good chance it will.) Nevertheless, as it stands we should face the fact that we’re not promising anything here.
I think that the answer to the first question is not at all to be dismissed: in my view, ongoing efforts to improve Python’s documentation should include an explanation of the fact that this example is safe in Python, differently from other languages. Notably including Java, a very popular high-level language. People with those background have every reason to be concerned about these problems, and we shouldn’t make the mistake of dismissing their concerns; something which was done not long ago by yours truly.
