> Bill Pugh wrote:
> > However, it does make it pretty difficult for the compiler
> > to do some undesirable transformations, such as
> > hoisting the volatile read out of the loop.
>
> Surely these are the sorts of optimisations that could never be made on
> volatiles - memory visibility aside - the compiler must always re-read a
> volatile as per the code in the program. ???
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. So
you might think that simply performing that transformation is equivalent to
working out a schedule where the read never happens after the write ahead of
time.
It is, in fact, perfectly fine for your VM never to schedule the reading
thread, as long as there is another thread that can be scheduled instead.
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.
Jeremy
-------------------------------
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