Jeremy Manson wrote:
> The trick is that if you have this code:
>
> do {
> r1 = v;
> } while (r1 == 0);
>
> then this code:
>
> r1 = v;
> do {
> } while (r1 == 0);
>
> Is equivalent to the original code for an execution where the thread that
> performs the read is never scheduled to occur after the write occurs.
> ...
> However, we don't want something like a source-to-bytecode compiler to
> perform this transformation and make it out-and-out impossible for the
> reading thread to get past the loop.
>
> Hence the suggested change.
I'm worried that the change is even necessary.
The original JMM in Chapter 17 of the JLS stated quite clearly that
reading/writing volatiles always went to "main memory" hence such
transformations were automatically disallowed.
I'm worried, as I've stated in the past, that the new JMM's philosophy that
the system "can do what it likes as long as it can't get caught", impacts on
scheduling/fairness issues that should not be part of the JMM. This includes
the examples of synchronized block merging, and moving accesses into
synchronized blocks. I feel the new JMM is too biased toward the JVM, at the
expense of a straight-forward programming model.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:03 EDT