Singleton Pattern- Non-trivial implementation concerns?

Back again to blogging - lets see how long will this spurt last. Hopefully for a longer duration as i get deeper into technology and find more interesting stuff to share.

The singleton pattern is interesting. Recently, while working on a project, I had to make use of it. I always believed that it was one of the most straightforward patterns to use. However, it was only later that I realised that there are a number of things which can go wrong.

Firstly, let me go forward and define it. Singleton pattern is used to define an object which will have only one instance created at any point of time. It will typically have a static accessor or a factory method to create that instance (preferably lazily).

public sealed class Singleton
{
    static Singleton instance=null;

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            if (instance==null)
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
}
While this looks like it will work perfectly, but one thing that is not taken care of is thread-safety. For example, if two threads checked the null test (instance == null) at the same time, then it could lead into two instances of the object being created. This is surely not desired.

So how to solve this? How about using a lock? Is that simple enough? Is performance going to suck then? Probably it will. Thats when I realised something like a singleton implementation which looks fairly simple on face value, might lead to non-trivial concerns realted to performance and laziness. So whats the solution for it?

 public sealed class Singleton
{
    static readonly Singleton instance=new Singleton();

    static Singleton()
    {
    }

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

Some of the key aspects of this solution are:

• The class is sealed and therefore, it cannot be inherited. Inheritance on the singleton could lead to more than one instances.
• According to .NET specificaitons, the static constructor is invoked only when any one of the static members is first accessed int he class. This implies that it is not strictly lazy, if there are other static members in this class.
• There is no need to check for if the object was null earlier everytime because .NET specification gaurantees that the static constructor is invoked only once. This gives a slight performance improvement.

For more detailed and insightful discussions check out:

https://www.yoda.arachsys.com/csharp/singleton.html
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/singletondespatt.asp