What is the point of double check locking?

Question

I have been reading the Wikipedia article on double check locking and one thing that's not clear from it (at least to me) is what the pattern achieves. What is the reason for making the two checks below? Why not have triple checked locking? Wouldn't that be even better?

if (mySingleton == null) { // 1st check
            lock (myLock) {
                if (mySingleton == null) { // 2nd (double) check
                    mySingleton = new MySingleton();
                }
            }
        }

Answer 1

The correct version without double check locking is:

lock (myLock) {
    if (mySingleton == null) { // 2nd (double) check
        mySingleton = new MySingleton();
    }
}

However this requires the expensive operation of getting a lock each time you want to get the singleton, however the lock is actually only need once (during the first initialization).

So the double check was introduce where a thread will check mySingleton outside the lock and if it passes the first check (mySingleton is not null) then you don't need to bother with acquiring the lock at all.

The inner check remains to avoid the race condition when 2 threads reach the lock block to initialize mySingleton however this can cause a double initialization if the inner check is not there (2 threads go in the lock block on at the time).

Adding a third check is useless, there are only 2 real states here: outside the lock and inside the lock. Where would you put the third check?

Answer 2

Locking is, was and always will be expensive because if you didn't get blocked, someone else is. Generally it is best to use libraries that encapsulate thread-sync in more efficient ways, using locks as a last resort.

But to answer the question as asked:

Think of a microphone being passed around an audience for people to ask questions. You don't request the microphone before you know you have a question to ask - that would be the first check. Then when you get the microphone, you have to recall the question and determine if it is still relevant.

Technically you could just request the mic and wait till you get it to decide if you have anything to say - and that would be very rude, annoying and while maybe you didn't notice a difference in waiting time - everyone after you does.

Answer 3

Its worth noting that in C# there is a thread safe approach that avoids the need to use locking for creating the singleton instance.

class MyClass
{
    //  Static constructor - Can only by called once per application domain.
    static MyClass()
    {
        //  We must be the only thread.
        MyClass.Instance = new MyClass(); 
    }

    static public MyClass Instance { get; private set; }

    protected MyClass()
    {
        //  Class constructor.
    }
}