matthewlynch.net Musings on programming, electronics, and other such things.

Thread-safe Singleton Initialisation

A co-worker who was unfamiliar with the singleton model recently asked me to explain the code to him; he was particularly curious about the locking on initialisation.

As it is fresh in my mind, I thought I might as well make a 'brief' post about it.

I am not going to go in to the singleton pattern itself - or the pros-and-cons; I am just going to cover the method I use for thread-safe initialisation in C#.

Like many people, I use double-checked locking during initialisation. It is actually a fairly simple concept, but looking at the code it can take a minute (or some explanation) before it clicks in to place...

public sealed class Example
{
   private static volatile Example m_Instance;
   private static object m_InstanceLock = new Object();

   private Example() {}

   public static Example Instance
   {
      get 
      {
         if (m_Instance == null) 
         {
            lock (m_InstanceLock) 
            {
               if (m_Instance == null)
               {
                  m_Instance = new Example();
               }
            }
         }

         return m_Instance;
      }
   }
}

Singletons are generally used with lazy initialisation. They are not initialised until they are first needed. The catch with this method of initialisation is that you run the very real risk of two threads attempting to initialise the singleton at the same time.

The only way to avoid this is to use locking, but this can add fairly significant overhead.

Do you have to lock every time someone attempts to access the instance? Well no, you don't... but to avoid doing so, you can't just lock the instance itself.

The solution is to create a separate, simple object that you lock only during initialisation.

To avoid having to lock every time a thread tries to get a reference to the instance, you first do a simple check to see if the instance is null. If it is not null, you simply return the instance. No locking required.

If the instance is null, however, the first thing you do is request a lock on the locking target.

Once you have the lock, you check to see if the instance is still null. Why do you check again? Well while you were waiting for a lock, another thread may have initialised the instance.

If the instance is still null you initialise it. If it is not null, you do nothing. In either case, you finally fall out to the standard return of the instance.

To ensure this pattern of initialisation works, the instance should be declared as volatile. This will prevent the .NET run-time - or the hardware - from creating issues by trying to be smart about optimising calls to the same object in a small space of time.

Generally speaking, declaring objects that will be used by multiple threads as volatile is worth consideration.