Singleton implementations in .NET

Technorati Tags: Design Patterns

The ‘gof design patterns’ book describes the intent of a singleton as follows: ‘Ensure a class has only one instance, and provide a global point of access to it’.
For a .NET application this means that there is one instance of the singleton type per application domain.
Following code snippet show a ‘generic’  (C++) implementation for the pattern:

   1: class Singleton {

   2: public:

   3:     static Singleton* Instance();

   4: protected:

   5:     Singleton();

   6: private:

   7:     static Singleton* _instance;

   8: };

   9: Singleton* Singleton::_instance = 0;

  10:  

  11: Singleton* Singleton::Instance () {

  12:     if (_instance == 0) {

  13:         _instance = new Singleton;

  14:     }

  15:     return _instance;

  16: }

** It should be noted that this implementation is not thread-safe. Calling the ‘Instance()’ method from multiple threads can result in the creation of more than one instance of the ‘Singleton’ class.

When creating an .NET implementation of the singleton pattern, the following functionality is either mandatory or desired:

Functionality	MoSCoW	Description
One instance per application domain	M	Ensures that there is only one instance of the type per application domain.
Thread-safe construction	M	Construction of the singleton type instance in a multithreaded/multicore environment must also result into one instance per application domain, regardless of any race conditions or compiler/processor optimizations.
Lazy initialization	S	The actual creation of the type instance is triggered by the first access to the singleton.
Initialization status indication	C	The possibility to test if the singleton instance has already been created (of course without creating it).
Re-initialization after exception	C	The possibility to re-trigger the creation of the singleton, should an exception have occurred during the previous attempt to create the instance of the singleton.

Basically we have there are two styles to implement the singleton pattern, we can rely on type initializers (aka. static constructors) or instantiate the singleton instance via the ‘Instance’ property getter (like the sample above does).

Common Features in all approaches

Following features are common to all approaches:

1. The instance constructor is private. (see Singleton Pattern and inheritance)
2. The singleton type is sealed. (see Singleton Pattern and inheritance)
3. The instance is stored in a private readonly static field.

Approach 1: Using the .NET Type constructor

In .NET a type constructor (also known as static constructor or class constructor or type initializer) is used to set the initial state of a type. You define a type constructor just like an instance constructor with the following exceptions:

1. It must be marked static.
2. It is automatically marked as private by the compiler.
3. It cannot have parameters.

Furthermore, the .NET CLR guarantees that a type constructor is only executed once for each type loaded in the application domain, and that the execution is thread-safe.

Following code shows the implementation:

   1: public sealed class SingletonApproach1

   2: {

   3:     private readonly static SingletonApproach1 instance;

   4:  

   5:     public static SingletonApproach1 Instance

   6:     {

   7:         get

   8:         {

   9:             return instance;

  10:         }

  11:     }

  12:  

  13:     static SingletonApproach1()

  14:     {

  15:         instance = new SingletonApproach1();

  16:     }

  17:  

  18:     private SingletonApproach1() { }

  19:  

  20:     public int P1 { get; set; }

  21: }

Example code using the singleton:

   1: class Program

   2: {

   3:     static void Main(string[] args)

   4:     {

   5:         const Int32 iterations = 1000 * 1000 * 1000;

   6:         PerfTest1(iterations);

   7:         PerfTest2(iterations);

   8:         PerfTest1(iterations);

   9:         Console.ReadLine();

  10:     }

  11:     static void PerfTest1(Int32 iterations)

  12:     {

  13:         Stopwatch sw = Stopwatch.StartNew();

  14:         for (Int32 x = 0; x < iterations; x++)

  15:         {

  16:             SingletonApproach1.Instance.P1 = 1;

  17:         }

  18:         Console.WriteLine("PerfTest1: {0}", sw.Elapsed);

  19:     }

  20:     static void PerfTest2(Int32 iterations)

  21:     {

  22:         Stopwatch sw = Stopwatch.StartNew();

  23:         for (Int32 x = 0; x < iterations; x++)

  24:         {

  25:             SingletonApproach1.Instance.P1 = 1;

  26:         }

  27:         Console.WriteLine("PerfTest2: {0}", sw.Elapsed);

  28:     }

  29: }

Remark that we do not (and cannot) call the type constructor. The call to the type constructor is automatically issued by the JIT-compiler when compiling the first method that accesses the type (either by creating an instance or accessing a static method, property or field).
In the example this happens when compiling the ‘PerfTest1’ method because it accesses the static ‘Instance’ property of the type.

Disadvantages of this approach

1. There is a performance penalty in the first method accessing the singleton because the JIT-compiler injects the call to the type initializer in this method. See the difference in execution time between ‘PerfTest1’ and ‘PerfTest2’ while both methods perform the same work.
   

   PerfTest1: 00:00:03.1461604 PerfTest2: 00:00:00.8905847 PerfTest1: 00:00:03.1043356

2. Exception Handling. When an exception occurs in the instance constructor this will make the type unusable and results in a ‘TypeInitializationException’ in the application code. Each subsequent use of the type will result in the same exception, and there is no way to re-execute the type initializer.
3. You cannot test if the singleton has already been initialized, since adding this test would lead to instantiating the singleton. This is caused by the fact that accessing a static field (other than ‘Instance’ in this case) will also trigger the execution of the type initializer.

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S	(When no other statics beside ‘Instance’ exist)
Initialization status indication	C
Re-initialization after exception	C

Approach 2: Using the .NET field initializer

   1: public sealed class SingletonApproach2

   2: {

   3:     private readonly static SingletonApproach2 instance = new SingletonApproach2();

   4:  

   5:     public static SingletonApproach2 Instance

   6:     {

   7:         get

   8:         {

   9:             return instance;

  10:         }

  11:     }

  12:  

  13:     private SingletonApproach2() { }

  14:  

  15:     public int P1 { get; set; }

  16: }

In this approach we replaced the type initializer with a field initializer. If we examine the generated IL-code for both approaches, it becomes clear that when using the field initializer approach, the compiler has generated a type initializer with a content that is exactly the same as the one we manually added in the type initializer approach.

The difference between the two implementations is in the metadata attributes of the singleton class. When we use a field initializer the class is decorated with the ‘beforefieldInit’ attribute, where this attribute is missing when we explicitly write the type initializer method.
The ‘beforefieldInit’ attribute defines the approach the JIT-compiler will use when it issues the code to call the type initializer.
Simply stated, when the ‘beforefieldInit’ attribute is present, the JIT-compiler has the freedom to choose when to invoke the type initializer as long as it is invoked before a reference to a static field or instance of the type is used. In other words the JIT-compiler is allowed to use optimizations when it comes to calling the type initializer. On the other hand, when the ‘beforefieldInit’ attribute is not present, the call to the type initializer will be placed exactly before the code accessing the static field or instance of the type. We call these behaviors the ‘beforefieldInit’ and the ‘Precise’ behavior.
The CLI specfication states the following regarding ‘beforefieldInit’:

A type may have a type-initializer method, or not. A type may be specified as having a relaxed semantic for its type-initializer method (for convenience below, we call this relaxed semantic BeforeFieldInit) If marked BeforeFieldInit then the type's initializer method is executed at, or sometime before, first access to any static field defined for that type If not marked BeforeFieldInit then that type's initializer method is executed at (i.e., is triggered by): first access to any static or instance field of that type, or first invocation of any static, instance or virtual method of that type

Whether or not the JIT-compiler is allowed to insert optimizations results in a performance difference between the two approaches. Generally speaking the ‘beforefieldInit’ approach result in better performance. Following code sample shows the results. Keep in mind that performance measurements can be misleading and must always be interpreted in the total context of the application. In this sample we executed the method calling the type initializer a billion times in the absence of any other application code, with the sole purpose to highlight the performance difference between the two approaches. In real life application the differences will not be that large, maybe even imperceptible.

Disadvantages of this approach

1. This approach has the same disadvantages as the ‘approach 1’, except for the performance penalty in the first method calling the singleton.
   Performance results are:
   

   PerfTest1: 00:00:00.9240271 PerfTest2: 00:00:00.9049068 PerfTest1: 00:00:00.8854748

2. This solution is not as lazy as it seems. Because the JIT-compiler has a greater degree of freedom it can place the call to the type initializer anywhere in the calling before the access to the singleton. Following example illustrates this behavior. You can see that the singleton is already created before the write to the console in the calling method.
   

      1: public sealed class SingletonApproach2

      2: {

      3:     private readonly static SingletonApproach2 instance = new SingletonApproach2();

      4:  

      5:     public static SingletonApproach2 Instance

      6:     {

      7:         get

      8:         {

      9:             return instance;

     10:         }

     11:     }

     12:  

     13:     private SingletonApproach2() { Console.WriteLine("Singleton created"); }

     14:  

     15:     public int P1 { get; set; }

     16: }

     17: class Program

     18: {

     19:     static void Main(string[] args)

     20:     {

     21:         Do();

     22:         Console.ReadLine();

     23:     }

     24:     static void Do()

     25:     {

     26:         Console.WriteLine("About to access the singleton");

     27:         SingletonApproach2.Instance.P1 = 1;

     28:     }

     29: }

   Singleton created About to access the singleton

   
   

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S	(When no other statics beside ‘Instance’ exist) Initialization may occur earlier in the method.
Initialization status indication	C
Re-initialization after exception	C

Approach 3: Using a simple lock

In order to implement the ‘Status Indication’ and ‘Re-initialization after exception’ features, we have to leave the type initializer approach and switch to the classical implementation where the singleton instance is constructed in the ‘Instance’ getter.

   1: public sealed class SingletonApproach3

   2: {

   3:     private static SingletonApproach3 instance;

   4:     private readonly static object synclock = new object();

   5:  

   6:     public static SingletonApproach3 Instance

   7:     {

   8:         get

   9:         {

  10:             lock (synclock)

  11:             {

  12:                 if (instance == null)

  13:                 {

  14:                     instance = new SingletonApproach3();

  15:                 }

  16:                 return instance;

  17:             }

  18:         }

  19:     }

  20:  

  21:     public static bool IsInitialized

  22:     {

  23:         get

  24:         {

  25:             lock (synclock)

  26:             {

  27:                 return instance != null;

  28:             }

  29:         }

  30:     }

  31:  

  32:     private SingletonApproach3() { }

  33:  

  34:     public int P1 { get; set; }

  35: }

This is a thread-safe implementation since the lock allows only one thread at a time to have access to the ‘Instance’ getter method and takes care of the ‘memory barrier’ problem because all reads occur after acquiring the lock and all writes occur before releasing the lock.

Disadvantages of this approach

1. There is a performance penalty caused by acquiring the lock on each access to the singleton instance.
   

   PerfTest1: 00:01:03.3850922

2. In a multi-thread application, getting a reference to the singleton instance is serialized, which may lead to scaling issues.

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S
Initialization status indication	C
Re-initialization after exception	C

Approach 4: Using lock with double check

Next code sample show the ‘double check’ implementation. There is a lot of discussion about the thread safety of this construction, due to possible compiler and multicore optimizations. Choosing for the solution to declare the instance field as ‘volatile’ ensures a thread-safe implementation in .NET.

   1: public sealed class SingletonApproach4

   2: {

   3:     private static volatile SingletonApproach4 instance;

   4:     private readonly static object synclock = new object();

   5:  

   6:     public static SingletonApproach4 Instance

   7:     {

   8:         get

   9:         {

  10:             if (instance == null)

  11:             {

  12:                 lock (synclock)

  13:                 {

  14:                     if (instance == null)

  15:                     {

  16:                         instance = new SingletonApproach4();

  17:                     }

  18:                 }

  19:             }

  20:             return instance;

  21:         }

  22:     }

  23:  

  24:     public static bool IsInitialized

  25:     {

  26:         get

  27:         {

  28:             lock (synclock)

  29:             {

  30:                 return instance != null;

  31:             }

  32:         }

  33:     }

  34:  

  35:     private SingletonApproach4() { }

  36:  

  37:     public int P1 { get; set; }

  38: }

Disadvantages of this approach

1. Although the performance is better than the simple lock version, it is still inferior to all other approaches.
   

   PerfTest1: 00:00:14.6866434

   
   

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S
Initialization status indication	C
Re-initialization after exception	C

Approach 5: Using .NET field initializer with true laziness

This approach is a variation of approach 2 where we deal with the lazy initialization. Using a nested class, true laziness is achieved.

   1: public sealed class SingletonApproach5

   2: {

   3:     public static SingletonApproach5 Instance

   4:     {

   5:         get

   6:         {

   7:             return Nested.instance;

   8:         }

   9:     }

  10:  

  11:     private SingletonApproach5() {}

  12:  

  13:     class Nested

  14:     {

  15:         internal readonly static SingletonApproach5 instance = new SingletonApproach5();

  16:         static Nested() { }

  17:     }

  18:  

  19:     public int P1 { get; set; }

  20: }

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S
Initialization status indication	C
Re-initialization after exception	C

Performance

Following table list the time elapsed to access the singleton one billion times with the first access instantiating the singleton. For approaches using the type initializer the time is shown for instantiating and non-instantiating methods.

Approach	Instantiating method	Non-instantiating method
1	00:00:03.1461604	00:00:00.8905847
2	00:00:00.9240271	00:00:00.9049068
3	00:01:03.3850922
4	00:00:14.6866434
5	00:00:00.9222056	00:00:00.8969283

Remark: Singleton Pattern and static class

So far, so good, but why didn’t we implement the singleton as a static class? A static class also offers the singleton behavior where it comes to the use of type initializers and thread safety while executing the type initializer. The main reason why a static class is not preferable as a singleton pattern implementation is that it severely limits OO capabilities because it cannot be used as a parameter in a method call and it cannot implement an interface.
Following code will not compile due to the limitations mentioned above:

   1: public interface IMySingleton

   2: {

   3:     int P1 { get; set; }

   4: }

   5:  

   6: public static class Singleton1 : IMySingleton

   7: {

   8:     public static int P1 { get; set; }

   9: }

  10:  

  11: public static class Singleton2 : IMySingleton

  12: {

  13:     public static int P1 { get; set; }

  14: }

  15:  

  16: class Program

  17: {

  18:     static void Main(string[] args)

  19:     {

  20:         DoSomethingWithASingleton(Singleton1);

  21:     }

  22:  

  23:     static void DoSomethingWithASingleton(IMySingleton s)

  24:     {

  25:         Console.WriteLine(s.P1);

  26:     }

  27: }

Remark: Singleton Pattern and inheritance

You may have noticed that the instance constructor of the singleton type is private so that application code cannot use the constructor to create instances of the singleton (which would violate the singleton pattern). Actually this makes the singleton type ‘not inheritable’ even without marking it ‘sealed’. We might ask the question whether the visibility of the instance constructor should be changed to ‘protected’ to allow inheritance.
It is my opinion that it should not be changed (as such not allowing inheritance) for the following reasons:

1. If inheritance is allowed, the derived type can add extra instance constructor(s) allowing application code to directly create instances of the singleton type. This is a violation of the singleton pattern (and of the ‘Liskov substitution principle’).
2. If you can derive ‘once’, you can also derive ‘twice’ (and more). This can result in multiple instances of the base singleton class, which is once more a violation of the singleton pattern. Following code sample illustrates this situation.

   1: public class MySingletonBeforeInit

   2: {

   3:     private readonly static MySingletonBeforeInit instance = new MySingletonBeforeInit();

   4:     public static MySingletonBeforeInit Current

   5:     {

   6:         get { return instance; }

   7:     }

   8:     public Guid P1 { get; set; }

   9:     protected MySingletonBeforeInit()

  10:     {

  11:         Console.WriteLine("Creating MySingletonBeforeInit");

  12:         this.P1 = Guid.NewGuid();

  13:     }

  14: }

  15: public class MySingletonDerived1 : MySingletonBeforeInit

  16: {

  17:     private readonly static MySingletonBeforeInit instance = new MySingletonDerived1();

  18:     public new static MySingletonBeforeInit Current

  19:     {

  20:         get { return instance; }

  21:     }

  22:     protected MySingletonDerived1() { Console.WriteLine("Creating MySingletonDerived1"); }

  23: }

  24: public class MySingletonDerived2 : MySingletonBeforeInit

  25: {

  26:     private readonly static MySingletonBeforeInit instance = new MySingletonDerived2();

  27:     public new static MySingletonBeforeInit Current

  28:     {

  29:         get { return instance; }

  30:     }

  31:     protected MySingletonDerived2() { Console.WriteLine("Creating MySingletonDerived2"); }

  32: }

  33: class Program

  34: {

  35:     static void Main(string[] args)

  36:     {

  37:         Console.WriteLine(MySingletonDerived1.Current.P1.ToString());

  38:         Console.WriteLine(MySingletonDerived2.Current.P1.ToString());

  39:         Console.WriteLine(MySingletonDerived1.Current.P1.ToString());

  40:         Console.WriteLine(MySingletonDerived2.Current.P1.ToString());

  41:         Console.ReadLine();

  42:     }

  43: }

Creating MySingletonBeforeInit Creating MySingletonDerived1 Creating MySingletonBeforeInit Creating MySingletonDerived2 07ed6401-131a-45b6-ae57-be6a685c00d9 5bef7ecb-3ccd-4101-a377-e50b93c3af87 07ed6401-131a-45b6-ae57-be6a685c00d9 5bef7ecb-3ccd-4101-a377-e50b93c3af87

Conclusion

Unless you need to test for initialization of the singleton, or need to ability to re-initialize after an exception (both are rarely needed in my opinion), Approach 2 is the preferred choice. It offers the best mix of functionality, performance and simplicity.
Keep in mind that in this article, I only talk about thread safety in the context of instantiating the singleton. When you use the singleton in a multi-threaded environment, it is still the programmer’s responsibility to write thread-safe implementation of the other methods and properties of the singleton type.