So we have we reached any conclusion whether the JMM allows for the write to
x to be moved ahead of the loop?
Eliot Moss stated that if x were volatile and there another volatile access
in the loop then the move would be prohibited. I argue that even if there
are no other volatile accesses in the loop the move still need to be
prohibited. Here's an example scenario that is "correctly synchronized:
Master thread fills in a buffer with work items and then starts a new worker
thread to process the buffer. Worker threads executes:
while (!buf.empty()) process(buf.take());
workerFinished = true;
where workerFinished is a volatile. Not quite as dramatic as firing the
missiles, but same basic problem.
Ras Bodik wrote:
> Condition 1: As far as I can tell, in any code that's
> guaranteed to run only in a single-threaded environment
> (which some compiler may assume), moving x:=1 prior to the loop
> is semantically harmless.
There is a generalization of the single-threaded vs multi-threaded aspect
that has me concerned. The condition is really that nothing else can see and
act upon the value of x. The situation that concerns me is if x is actually
a memory-mapped hardware register. Now that doesn't occur in stock-standard
J2SE but it can in, for example, a Real-time Specification for Java VM. In
principle I would expect some of the J2ME platforms to provide physical
memory access as well. In such situations there seems little, if any,
support, for the programmer to flag such variables in a way that tells the
compiler not to do anything fancy with them. It would seem that a RTSJ VM,
for example, must ensure that it's JIT (or AOT system) understands about
PhysicalMemory regions and treats all accesses to the specially.
On one hand that's fair enough. What concerns me though is how the providers
of such a system will realise that they need to do something special -
especially if they license third-party JIT/AOT technology.
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:08 EDT