Fixing Double-Checked Locking using Volatile

Question

Oooh - what a scandalous subject title! :)
Anyhow, I was expanding my knowledge on why the double-checked locking idiom used in Singleton classes fails (after reading that JSR-133 is not going to fix the problem!), when I read http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html and found a spicy section titled "Fixing Double-Checked Locking using Volatile" (at the very bottom of the document).
As it is quite hard to find information (all sources revisit all the basic problems), I was wondering if anybody could back this up/refute it.
Just one more thing. I anticipate that many people who are researching this matter would like to have this clarified, so it would be beneficial to keep posts very much on topic. There is already a lot of information available about double locking failures in general.
The problem this post faces lies in a lot of statements saying "using volatile will NOT fix double-checked locking" that refer (I think) to the current JDK.
Thanks heaps!

Answer 1

Volatile only checks that not more than one thread is accessing the variable at the same time (amongst other things of course), so in the example, it could cause problems. Let me explain a little here. Given a situation where two threads wish to aquire the Helper:
Step 1: Thread 1 enters the method and checks the helper status
and sees that it is null.
private volatile Helper helper = null;
public Helper getHelper() {
  if (helper == null) { // <!-- Thread 1 requires helper, and sees that it is null
     synchronized(this) {
        if (helper == null)
           helper = new Helper();
   return helper;
}Step 2: Thread 2 enters the method, before the lock can be
acquired on the this-object and notices that the helper is
null.
private volatile Helper helper = null;
public Helper getHelper() {
  if (helper == null) { // <!-- Thread 2 requires helper also
     synchronized(this) { // and it is still null
        if (helper == null)
           helper = new Helper();
   return helper;
}Step 3: The first Thread creates a new Helper
private volatile Helper helper = null;
public Helper getHelper() {
  if (helper == null) { // <!-- Thread 2 waiting for lock realeas
     synchronized(this) {
        if (helper == null)
           helper = new Helper(); // <!-- Thread 1 creating new Helper
   return helper; //
}Now for Step 4, there are a few possibilites here. Either Thread 1 returns the helper it created, or Thread 2 can create the new Helper before the Thread 1 returns the Helper. Either way, the result is unwanted.
private volatile Helper helper = null;
public Helper getHelper() {
  if (helper == null) {
     synchronized(this) {
        if (helper == null)
           helper = new Helper(); // <!-- Thread 2 creating new Helper
   return helper; // <!-- Thread 1 returning Helper
}The code can also create interesting situations (deadlocks?) due to the synchronized(this) statement used in a ... creative way in this case.
I might be wrong of course. Just my �0.02.
Tuomas Rinta