The need for volatile modifier in double checked locking in .NET

Question

Multiple texts say that when implementing double-checked locking in .NET the field you are locking on should have volatile modifier applied. But why exactly? Considering the following example:

public sealed class Singleton {    private static volatile Singleton instance;    private static object syncRoot = new Object();     private Singleton() {}     public static Singleton Instance    {       get        {          if (instance == null)           {             lock (syncRoot)              {                if (instance == null)                    instance = new Singleton();             }          }           return instance;       }    } } 

why doesn't "lock (syncRoot)" accomplish the necessary memory consistency? Isn't it true that after "lock" statement both read and write would be volatile and so the necessary consistency would be accomplished?

Answer 1

Volatile is unnecessary. Well, sort of**

volatile is used to create a memory barrier* between reads and writes on the variable.
lock, when used, causes memory barriers to be created around the block inside the lock, in addition to limiting access to the block to one thread.
Memory barriers make it so each thread reads the most current value of the variable (not a local value cached in some register) and that the compiler doesn't reorder statements. Using volatile is unnecessary** because you've already got a lock.

Joseph Albahari explains this stuff way better than I ever could.

And be sure to check out Jon Skeet's guide to implementing the singleton in C#

update:
*volatile causes reads of the variable to be VolatileReads and writes to be VolatileWrites, which on x86 and x64 on CLR, are implemented with a MemoryBarrier. They may be finer grained on other systems.

**my answer is only correct if you are using the CLR on x86 and x64 processors. It might be true in other memory models, like on Mono (and other implementations), Itanium64 and future hardware. This is what Jon is referring to in his article in the "gotchas" for double checked locking.

Doing one of {marking the variable as volatile, reading it with Thread.VolatileRead, or inserting a call to Thread.MemoryBarrier} might be necessary for the code to work properly in a weak memory model situation.

From what I understand, on the CLR (even on IA64), writes are never reordered (writes always have release semantics). However, on IA64, reads may be reordered to come before writes, unless they are marked volatile. Unfortuantely, I do not have access to IA64 hardware to play with, so anything I say about it would be speculation.

i've also found these articles helpful:
http://www.codeproject.com/KB/tips/MemoryBarrier.aspx
vance morrison's article (everything links to this, it talks about double checked locking)
chris brumme's article (everything links to this)
Joe Duffy: Broken Variants of Double Checked Locking

luis abreu's series on multithreading give a nice overview of the concepts too
http://msmvps.com/blogs/luisabreu/archive/2009/06/29/multithreading-load-and-store-reordering.aspx
http://msmvps.com/blogs/luisabreu/archive/2009/07/03/multithreading-introducing-memory-fences.aspx

Answer 2

There is a way to implement it without volatile field. I'll explain it...

I think that it is memory access reordering inside the lock that is dangerous, such that you can get a not completelly initialized instance outside of the lock. To avoid this I do this:

public sealed class Singleton {    private static Singleton instance;    private static object syncRoot = new Object();     private Singleton() {}     public static Singleton Instance    {       get        {          // very fast test, without implicit memory barriers or locks          if (instance == null)          {             lock (syncRoot)             {                if (instance == null)                {                     var temp = new Singleton();                      // ensures that the instance is well initialized,                     // and only then, it assigns the static variable.                     System.Threading.Thread.MemoryBarrier();                     instance = temp;                }             }          }           return instance;       }    } } 

Understanding the code

Imagine that there are some initialization code inside the constructor of the Singleton class. If these instructions are reordered after the field is set with the address of the new object, then you have an incomplete instance... imagine that the class has this code:

private int _value; public int Value { get { return this._value; } }  private Singleton() {     this._value = 1; } 

Now imagine a call to the constructor using the new operator:

instance = new Singleton(); 

This can be expanded to these operations:

ptr = allocate memory for Singleton; set ptr._value to 1; set Singleton.instance to ptr; 

What if I reorder these instructions like this:

ptr = allocate memory for Singleton; set Singleton.instance to ptr; set ptr._value to 1; 

Does it make a difference? NO if you think of a single thread. YES if you think of multiple threads... what if the thread is interruped just after set instance to ptr:

ptr = allocate memory for Singleton; set Singleton.instance to ptr; -- thread interruped here, this can happen inside a lock -- set ptr._value to 1; -- Singleton.instance is not completelly initialized 

That is what the memory barrier avoids, by not allowing memory access reordering:

ptr = allocate memory for Singleton; set temp to ptr; // temp is a local variable (that is important) set ptr._value to 1; -- memory barrier... cannot reorder writes after this point, or reads before it -- -- Singleton.instance is still null -- set Singleton.instance to temp; 

Happy coding!