Joe,
Thanks, that looks like a good example.
I had been thinking about moving a single volatile read up into a
synchronized block. But obviously, moving a loop with volatile reads
into a synchronized block causes problems.
There is an implementation issue related to whether it is legal to
move some finite number of volatile reads up into a synchronized
block. On an architecture such as the IA-64, a monitorexit will
typically be implemented as a st.rel (store/release instruction),
with additional housekeeping. A volatile read would be executed as a
ld.acq (load/acquire instruction). In order to prevent a monitorexit
and a following volatile read from being reordered by the memory
system, an additional memory barrier between them would be required.
Is that memory barrier required? I would certainly be nice if it wasn't.
Reordering a monitorexit and a finite number of volatile reads may
fall into the category of something that is illegal in the semantics,
but can't be observed so is legal in the implementation.
Can anyone come up with an example where you could detect that a
monitorexit and a single following volatile read had been reordered?
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT