At 2:30 PM -0500 12/15/00, Robert Munyer wrote:
>BUT I was not able to think of any idiom using volatile that would work
>correctly according to the JLS. If I understand the rules of Chapter 17
>correctly, the only way to get volatile to work correctly in the code below
>would be to add a volatile modifier to EVERY variable that is visible
>through the variable "helper."
We are proposing to strengthen volatile, so that only the helper
field would need to be volatile.
>
>Do you mean it will not work correctly, regardless of the value of the
>optimization flag? Or do you mean it will not work correctly if the flag is
>set to 'true' on those machines?
I misread something in your code. I now see your intent: to have two
versions of the code: one for the Alpha, another for other platforms.
A simpler way to write it would be:
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (GlobalSettings.allowsDependentReadsToBeReordered || helper != null) {
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
}
This still doesn't work on systems where
GlobalSettings.allowsDependentReadsToBeReordered is false, unless you
also prohibit reordering of writes (by either the compiler or
processor). There are various ways to try to hack around it, but they
are all ugly.
More importantly, if such flags were available, 99.999999% of all
programmers who used them would use them incorrectly. I would like to
avoid putting too many loaded guns into the revised spec.
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:29 EDT