Re: Another DCL-like approach, correct or broken?
Lew wrote:
Piotr Kobzda wrote:
[...]
OK, so let's make it a bit simpler:
public abstract class SingletonReference<T> {
private static final class ValueHolder<T> {
final T value;
ValueHolder(final T value) {
this.value = value;
}
}
private ValueHolder<T> valueHolder;
protected abstract T initialValue();
public final T get() {
if (valueHolder == null) {
This needs to be synchronized or another thread might slip in between
the null check and the critical section.
What's the problem with that? Why should one thread care if other
thread is sleeping or not in between?
AFAIK, the only problems with old JMM here I recall, was ability to read
unsynchronized variable too early, i.e. without all fields of this
variable fully initialized.
But now, thanks to the final field semantics, it seems that we don't
have to care about this problem:
"A thread that can only see a reference to an object after that object
has been completely initialized is guaranteed to see the correctly
initialized values for that object's final fields." [JLS3 17.5]
synchronized (this) {
if (valueHolder == null) {
valueHolder = new ValueHolder<T>(initialValue());
}
}
}
return valueHolder.value;
}
}
Now, it's classic DCL idiom supported by final field initialization
semantics. No volatile field is used.
Do you think it's correct?
Clearly not.
I'm not as certain of that as you are.
Especially in face of some other citations:
"If Helper is an immutable object, such that all of the fields of Helper
are final, then double-checked locking will work without having to use
volatile fields." [the Declaration mentioned earlier]
"Final fields also allow programmers to implement thread-safe immutable
objects without synchronization. A thread-safe immutable object is seen
as immutable by all threads, even if a data race is used to pass
references to the immutable object between threads. This can provide
safety guarantees against misuse of an immutable class by incorrect or
malicious code. Final fields must be used correctly to provide a
guarantee of immutability." [JLS3 17.5]
What's wrong with the normal suggested solution to this idiom?
What is the normal suggested solution you think of?
piotr