Link Details

> This means that the victim thread could see the initial written value till end of time.

If that is the case, we would be in serious trouble now? I agree that the victim thread might not get the most recent value of the stop variable right away, but it will get it. The article implies that when a Swing GUI thread modifies a variable, that variable might never be read correctly by a second thread.

Or is my assumption wrong?

>> If that is the case, we would be in serious trouble now?

It depends :)

>>I agree that the victim thread might not get the most recent
>>value of the stop variable right away, but it will get it.

No guarantees are made. And as the example shows, the compiler could transform the code to something where the stop variable certainly won't become visible in the running thread (the read has been lifted out of the loop).

>>The article implies that when a Swing GUI thread modifies a variable,
>>that variable might never be read correctly by a second thread.

That could be the case. That is why it is very important that you know what you are doing when writing concurrent code. With the increasing number of cores, a strong cache coherence could limit scalability, so the chance is quite big that the strength of the cache coherence will be lowered. So code that runs correctly for the moment, could lead to problems when modern cpu's are used.

Thanks, I get the point. However, the problem is not actually with the code then, but with how Java handles concurrency. So with Java we have automated memory management but as it turns out, Java behaves very irrational when it comes to updating a variable...

I agree that it is unexpected. But if you know the JMM, it isn't that difficult. The big advantage (for us Java developers) is that the new JMM allows for all kinds of transformations that increase the performance of our applications, and that is a good thing. The old JMM wasn't well defined, so it was very tricky to build a good behaving and performing virtual machine. In older vm's the final even isn't final :)

If you make all variables volatile (or final) the application would be sequentially consistent (this is the model most developers have of concurrent programs). Sequential consistency is all possible interleavings of instructions (executed by multiple threads) that obey program order (the order instructions have in the source code). It would be a nice experiment to see what happens to the performance of applications if we make them sequential consistent by some kind of bytecode modification tool: replacing all normal writes/reads by volatile writes/reads.

PS: you only need to worry about these issues when you are writing multi threaded programs (when objects are shared between threads to be more precise). Transformation of instructions is not allowed to be visible within a single thread, so we don't need to worry about that.