Double-Check idom, ThreadLocal and volatile

[Timo Nentwig]

Hi!

I just read
http://www.javaworld.com/javaworld/jw-11-2001/jw-1116-dcl.html (which
was written back in 2001!). Well, I've seen a lot of Double-Check Lock
(DCL) code and can't remember to ever have seen any usage of
ThreadLocal. I am wondering whether the getInstance() problem cannot be
solved by volatile (I confess that I yet didn't understand volatile
completely). So, my getInstance() (or getResource() as it's named in
the article) would look like this:

class VolatileDCL {
private static volatile Resource resource = null;

public static Resource getInstance() {
if(resource == null)
{
synchronized(this)
{
if(resource==null)
resource = new Ressource();
}
}
return resource;
}

Seriously, how often does bytecode reordering lead to problems in the
real world? I'm really surprised that virtually no developer does seem
to care...

 

[alexandre_paterson]

Well, I've seen a lot of Double-Check Lock
(DCL) code and can't remember to ever have seen any usage of
ThreadLocal.

The real problem is that you've seen the double-check lock at all,
not how it was implemented

I am wondering whether the getInstance() problem cannot be
solved by volatile (I confess that I yet didn't understand volatile
completely). So, my getInstance() (or getResource() as it's named in
the article) would look like this:

class VolatileDCL {
private static volatile Resource resource = null;

public static Resource getInstance() {
if(resource == null)
{
synchronized(this)
{
if(resource==null)
resource = new Ressource();
}
}
return resource;
}

What it is the whole point of double-checked locking?

Having lazy instantiation while avoiding the cost of
the mechanism ensuring mutual exclusion, right?

Volatile is a mechanism to enforce mutual exclusion on
shared variable "that is more convenient than locking
for some purposes" [sic] (JLS 8.1.3)

As I understand it though, volatile still has a cost...

While the point of double-checked locking is to have
a lazy instantiation free ride.

And that is entirely doable in the case you mentionned.

For example:

private static class RessourceHolder {
static final ressource = new Ressouce();
}

public static Ressource getInstance() {
return RessourceHolder.ressource;
}

And as a benefit, it looks way less clumsy than any
kind of (broken) double-checked locking code.

This is described as the "initialize-on-demand holder
class idiom" in Joshua Bloch's "Effective Java" book,
as a fix for the "broken double-check idiom for
lazy instantiation" [sic].

"The idiom takes advantage of the guarantee that a
"class will not be initialized until it is used [JLS 12.4.1]

No cost for the synchronization mechanism, no cost
for the volatile mechanism.

There you have it: lazy instantiation without the cost
for any mechanism ensuring mutual exclusion.

I'm really surprised that virtually no developer
does seem to care...

Are there really *that* many circumstances where an
object is so heavy to instantiate that it needs lazy
instantiation and that afterwards, once instantiated,
is accessed so often that the cost of synchronization is
too high?

I'm fully aware of the (correct) alternatives to the
double-check idiom since years (when did "Effective
Java" came out? and yet don't use such techniques
very often.

Hope it helps,