I've had a chance to read the recent postings. I think there's been some
real progress!
Here's my $0.02.
Datapoint: In my copy of the Java2 sources, dated 2/12/99, there are
only 9 files that contain the word 'volatile' and only one actual
volatile variable. The single volatile variable is in the Agent.java
source (part of sun.tools.agent).
My "opinion" about volatile is that it's a wart. Aesthetically, it
should either be removed or should be limited to V1 V2 semantics.
However, I realize that we're in a pickle with this JMM thing and I can
see how volatile might turn out to be a useful remedy. In fact,
providing a bandaid for broken code is the only reason I can see for
strengthening volatile. However, if that is the objective, I suggest we
look closely at the broken code we're trying to fix, and not dream up
new uses for a stronger volatile.
As for Doug's idea of introducing privileged classes for final and
volatile arrays, I'd rather see sync'd collections and sync'd
parameterized collections (GJ) used for this purpose. Volatiles are so
rarely used now, I can't see the utility.
At some point Bill Pugh said this about FinalArray:
"In favor of the idea that if we do it at all, we should do it at
the language level: this would allow functions such as
Class.getSigners() to return a reference to a final array of signers,
rather than making a copy each time getSigners is invoked (expensive) or
returning a reference to an unfinal array (implemented this way
originally, an serious security hole that has now been closed)."
Note: Unless these final arrays are more immune to mucking by native
code than ordinary final fields (or both are made immune), final arrays
are not a secure option.
-- Joe Bowbeer------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT