> Thread 3 is allowed to load helper and/or its fields
> from main memory BEFORE it enters the getHelper method, and
> then use those old values after it sees that helperExists is true.
If you interpret the spec such that it allows for a thread to read a value
an arbitrary amount of time before it is used, and that such reads can occur
in any order - then you are correct. But that is about as loose an
interpretation of the spec that is possible. But we've long since given up
arguing over how Ch17 should be interpreted.
> That's why the Boolean configuration parameter is necessary, and why it
must
> not be set to "true" if the program is running on certain machines (Alpha,
> and possibly others?).
Surely if you have ascertained whether or not it is correct to set the
parameter to true then the complex logic is unnecessary - as Bill already
suggested? The runtime actions of the code do not prove anything so you
should be able to do something like:
if (!Config.UNSYNC_READS_ALLOWED || helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
}
return helper;
Of course, Config.UNSYNC_READS_ALLOWED must be volatile to ensure the
correct value of it is seen.
> If I understand you correctly, it sounds like under the new
> memory model, the code above will still work if the Boolean is set to
> "false" -- but it won't run as fast as code that has been custom-designed
for
> the new spec by using "volatile."
Under the new memory model the code will fail in both cases. In the case of
"false" the code will fail if the thread sees "true" instead - because it
will be allowed to see garbage when no synchronisation is used. If
helperExists is made volatile then that can't happen - but under the new
spec, when it is volatile you won't need the original code anyway.
> Note, however, that any such code using volatile would
> need to have a similar Boolean configuration parameter, if you want it to
be
> backward-compatible with JVMs that use the original Chapter 17 memory
model.
Well if you can find a VM that implements Ch17 as it stands and which runs
on a weakly ordered machine - then you are probably right. In practice I
don't think there is such a beast.
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:00:29 EDT