The singleton pattern revolves around the mantra of their only ever being one instance of a type that is publicly available. Almost instantly you may be thinking of the
static modifier that is present in C# and several other popular languages. When you declare something as being
static you are declaring data that is associated with the type rather than an instance of that type. As we will see in this article this is a perfectly sensible approach to take, yet it does have some caveats as we will indeed discuss.
Our journey in this part of the design patterns series however will start with a very primitive design and implementation of the singleton design pattern.
Design Patterns Series
Part 1 Learn how to design more robust and maintainable code by incorporating design patterns into your software projects.
Part 2 This part shows the observer design pattern.
Part 3 In this part you will learn about the factory pattern.
Part 4 This part of the design patterns covers the singleton pattern.
Part 5 In this part of the design patterns series we investigate the command pattern and its uses.
Part 6 In this part of the design patterns series we will look at the adapter pattern.
Part 7 In this part of the design patterns series we will take a look at the template pattern.
How is a singleton typically implemented?
Normally a singleton type is publicly viewable within the context of its use yet its constructor is private. By making the constructor private only the type itself can instantiate the type. An instance of the type is usually created upon the invocation of a method whose sole purpose is to a) verify that an instance of the type is not already available; and b) if a) was true then instantiate an instance of the type. The constraint in a) will only ever be true once, if this property doesn’t hold then we don’t have a singleton. Generally the method that contains this logic is named something like
GetInstance. The former convention is fairly popular across various platforms and it describes the intent of the method well. As we are using C# and with the knowledge that C# supports properties we will use a getter property called
Instance which will contain a small amount of logic to verify the constraint mentioned previously.
Now that we have described a little about the singleton we can at least push on and create a type that implements those ideas in which we have discussed. For our example we will base it upon the prime minister (or president depending upon your location) of a country, of which there is only ever one at any one time. The following Figure shows the UML for our example.
Figure 1: Prime minister singleton
As you can tell the singleton pattern is very simple, thus far it is conceptually the most trivial we have encountered. The Instance property as mentioned prior will enforce our singleton constraint. The constraint being that only one instance of type
PrimeMinister is available for all those who are interested.
Before we proceed we should at least reiterate over a few key details about the
static modifier. We already noted in the introduction that
static members and methods are associated with the type rather than an instance of the type. Moreover if you come across a class that is annotated with the
static modifier then you cannot create an instance of it.
The following listing shows the implementation of our singleton
The code described in the previous listing can be used as follows.
There is glaring issue with our singleton implementation. The issue is directly connected with the constraint listed in a). Don’t worry if the problem isn’t apparent to you at the present time, we will cover this in due course.
A pretty interesting property of the singleton design pattern is that the instance of the
PrimeMinister type won’t be instantiated until someone actually wants an instance of the
PrimeMinister type. We can look at this as being good and bad, for example if we have clients that will be requesting an instance of the
PrimeMinister type all the time then this approach is most likely going to be marginally slower. A solution may just be to use the
static modifier and scrap the lazy like instantiation of our type altogether. More on this later.
The static modifier
To start this section we will present a slightly different approach for a
The major difference is one of context. The design that we originally implemented would instantiate an instance of
PrimeMinister only if someone actually referenced the
Instance property. In the latter however, the instance of
PrimeMinister is created irrespective of the fact if anyone actually uses it. The difference between the two then revolves around the time of instantiation. We can think of the version presented in this section as instantiating the
PrimeMinister type at load time, rather than runtime. This description isn’t entirely correct, however for the time being though it may help the reader to differentiate between the two. We will discuss about the technicalities imposed upon us by the use of the
static modifier later.
I feel almost compelled to mention that we could have instantiated the
PrimeMinister object within a static constructor. Keep this in mind as the provision of a
static constructor holds some significance later on.
Issues with our first design
The problem with our first design is that it’s not thread safe, and as a result we can’t guarantee that only one instance of
PrimeMinister will be around. Because of this issue our first design isn’t a very good singleton, in fact you should never use it. In contrast the version of our singleton that instantiated the instance of
PrimeMinister statically is thread safe.
In the second version we rely on the just-in-time (JIT) compiler to instantiate the
PrimeMinister singleton instance before it is referenced. We will provide a little more discussion about how the JIT guarantees this behavior later on.
How can we make our original design thread safe? The original design can be made thread safe by using a single lock that encapsulates a) and b).
While writing this article I wanted to look at the behavior of the
beforefieldinit intermediate language (IL) modifier a little more. This modifier is added to any class that has a
static field. Incidentally this modifier is not present if you provide a
After searching around to find out the behavior of this modifier I found the MSDN documentation pretty hazy. I stumbled across a pretty interesting performance article on MSDN  which opened with the following paragraph:
“When a type declares an explicit static constructor, the just-in-time (JIT) compiler adds a check to each of the type's static methods and instance constructors to ensure that the static constructor was previously called. Static initialization is triggered when any static member is accessed or when an instance of the type is created. However, static initialization is not triggered if you declare a variable of the type but do not use it, which can be important if the initialization changes global state.”
The following paragraph from the referenced article describes the approach that we currently use:
“When all static data is initialized inline and an explicit static constructor is not declared, Microsoft intermediate language (MSIL) compilers add the beforefieldinit flag and an implicit static constructor, which initializes the static data, to the MSIL type definition. When the JIT compiler encounters the beforefieldinit flag, in most cases the static constructor checks are not added. Static initialization is guaranteed to occur at some time before any of the static fields are accessed but not before a static method or instance constructor is invoked. Note that static initialization can occur at any time after a variable of the type is declared.”
The key point here is “Static initialization is guaranteed to occur at some time before any of the static fields are accessed but not before a static method or instance constructor is invoked” As it turns out then the design that we presented before the one that used a lock seems to be pretty efficient as the JIT won’t check that the static constructor was previously called, but it will guarantee that by the first time we reference the static field (which is in the return in
Instance) that it will be initialized. Having said this, and after consultation with Jon Skeet  I have opted to go with the use of a static constructor so that the
PrimeMinister class is never initialized unnecessarily. The following listing is our final version of the
In this article we have looked at several ways to implement a singleton ranging from the unsuitable (our first design) to the more suitable. As we have seen the singleton design pattern is trivial to understand however the key to enforcing a singleton is by making the implementation thread safe. For the latter we looked at three different versions, two of which used the
static C# modifier, the other using a
lock. In the first implementation using the static modifier we relied on the JIT to initialize our singleton object, in the second we enforced that the singleton type instance would not be instantiated unnecessarily.
As you can tell from this article there are a number of ways to create a thread safe singleton type and we have by no means exhausted all these approaches. However, we have covered several very common approaches to the implementation of a thread safe singleton. For further ideas on thread safe singleton approaches you can check out the ones that Jon presents , and Scott Galloway also presents another interesting approach .
I’d like to thank Jon Skeet  who cleared up some of the issues I had relating to the
beforefieldinit modifier and its associated behavior.
Sorry, no bio is available
This author has published 32 articles on DotNetSlackers. View other articles or the complete profile here.
Other articles in this category
Introduction to StructureMap
Have you heard of StructureMap, generally know what it’s for, and want to know how to get started qu...
The Command Pattern
In this article I will provide a quick refresher on what the command pattern is used for, how it wor...
DI Patterns: Constructor Injection
In this article, an excerpt from the book "Dependency Injection in .NET", we will take a detailed lo...
Brian Mains discusses how to implement the Arrange-Act-Assert pattern in TypeMock.
Key Process Patterns
This article, based on chapter 2 of Specification by Example, presents effective patterns for softwa...
You might also be interested in the following related blog posts
Learn design patterns from real projects: JBoss case study (Part 1).
Designing a Windows 8 Metro style app starting from an existing Windows Phone app Design Case Study Part 1
Introducing SharePoint 2010 Training at U2U
The Underground at PDC
12 ASP.NET MVC Best Practices
Screencast Whats new in the Entity Data Model Designer in VS2010
What needed to be monitored to get better Governance
SharePoint 2010 Workflow
Formatting Text in RadControls for WinForms Q3 2009
Please login to rate or to leave a comment.