Re: Another DCL-like approach, correct or broken?
Lew wrote:
I see what you mean, but even in the case of the primitive variable, to
which the article compares the use of an immutable object ("should
behave in much the same way as an int or float"), you will note that the
check for whether the variable is 0 ('null') is inside the critical
section, not outside as you coded it.
I'm sorry, I don't get it. The check is in two places, inside and
outside the critical section. That's what "double-checking" idiom
claims by its name, isn't it?
The read associated with outer check may be reordered with other reads
(or writes), but independently of the value used for check, there seems
to be no more than two possibilities: 1) method will exit with non-null
(final) value, fully initialized thanks to the new memory model
semantics (IIUIC!), or 2) will enter the critical section with inner
check, and then will exit with fresh value -- am I missing something?
What's wrong with the normal suggested solution to this idiom?
What is the normal suggested solution you think of?
Google on Brian Goetz and "double-checked locking".
I know Brian Goetz's excellent articles, the one I like the most is:
http://www.ibm.com/developerworks/library/j-jtp03304/
(also part 1 is worth of read, as well as his other articles...)
Unfortunately, Goetz suggest nothing special I can reuse in my utility
class (there are some additional features expected, not mentioned here
before, which can not be easily achieved using every commonly known
approach, for example, the check if initialization was performed without
causing the initialization cannot be done with nested holder class...)
The only solutions which seems to be acceptable to me are:
a) the DCL with volatile (the one broken under old JMM, but claimed
by most people to be correct now),
b) final fields initialization semantics based (my "a bit simpler"
approach, correctness of which I'm still not sure...),
c) my "another DCL-like" approach (from originating article of this
thread, not commented yet (I still hope: yet!)),
d) always synchronized access (no DCL in use at all).
My micro benchmarks shows that b) and c) are bit faster than a) (about
10%), and all are faster than d) (more than 10 times).
Do you know any other approach worth of looking at also?
Your example 'get()' method is exactly parallel to the example of what
does not work in the article you cited. That article explains why the
'Helper', or in your case, the 'ValueHolder', needs to be 'volatile', or
else checked for 'null' inside the critical section the way primitives
are checked for 0.
You did neither.
Again, from the article you quoted - note that the check for whether
'cachedHashCode' is zero is inside the critical section:
synchronized(this) {
if (cachedHashCode != 0) return cachedHashCode;
h = computeHashCode();
cachedHashCode = h;
}
Note that there is also the check outside the critical section in the
example you quoted, complete example method's body is as follows:
int h = cachedHashCode;
if (h == 0) // check #1
synchronized(this) {
if (cachedHashCode != 0) return cachedHashCode; // check #2
h = computeHashCode();
cachedHashCode = h;
}
return h;
To use an immutable object similarly, as the article suggests, you also
have to move the check for 'null' inside the critical section.
That check (#2) is already there:
if (valueHolder == null) { // check #1
synchronized (this) {
if (valueHolder == null) { // check #2
valueHolder = new ValueHolder<T>(initialValue());
}
}
}
Assuming my 'ValueHolder' is immutable (which, I think, is a case here),
what is the difference between the two above examples? Or, if it really
matters, between 'int's based, and the following one:
ValueHolder h = valueHolder;
if (h == null) { // check #1
synchronized (this) {
if (valueHolder != null) return valueHolder; // check #2
valueHolder = h = new ValueHolder<T>(initialValue());
}
}
return h;
?
I see no difference, sorry...
But OK, let's back to my initial post in this thread, and the approach
presented there. I'm interested the most in comments on it, because it
seems to support both memory models (old, and new one), and is free of
"heavy" synchronization after lazy creation of the value (not to
mention, that it gives me some other interesting features...).
So, what do you think about the "DCL-like" approach? Is it also broken
to you?
piotr