Huge cc list trimmed because everyone seems to be on this list anyway.
At 02:39 PM 17/05/2004 -0400, Bill Pugh wrote:
>Essentially, it gives us three guarantees:
>* if there exists some thread that is able to make progress, some thread
>will make progress
>* compilers cannot, in general, hoist volatile reads out of potentially
>infinite loops
>* compilers cannot, in general, reorder synchronization actions and
>externally visible actions
I'm unclear as to how the catatonia action achieves the second of them, in
particular.
Taking the original example
v is volatile and initially v = 0
Thread 1:
while(v == 0);
println("thread 1 done");
Thread 2:
v = 1
println("thread 2 done");
My current understanding is that the v == 0 test cannot be hoist from the
loop because doing so would leave thread 1 in an infinite loop that does
nothing, but the program contains no catatonia action, so the resulting
program does not fit the model.
But consider
i not volatile.
Thread 1:
while(v == 0) {
i++;
}
println("thread 1 done");
What's to stop the hoist now? The resulting loop would still contain memory
operations, so no catatonia action is required, and there are no hb
relationships that would be violated that I can see.
Alternatively, could you explain how the existence in the model of
catatonia actions prohibits the volatile read hoist in the second case.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:07 EDT