Proper implementation of Singleton pattern

Singleton pattern is one of the most essential patterns when it is applied correctly. There are some paramount tips and trick to be considered to get maximum efficiency of this pattern. This post will be all about implementing singleton pattern properly to avoid its misapplications.

When should I implement it?

The #1 reason to implement Singleton pattern is the need to restrict multiple instantiation of a class to at most one single instance. If you don’t need to keep at most one instance of a class, then you should consider the classical way of class implementations, i.e. either static of non-static, to keep the design simple to maintain.

The #2 additional reason is the need for thread safety of single instance method.  Otherwise, it may be also wise to implement a conventional static method without singleton pattern.

Note: Most of the time, the first reason is considered to be sufficient to implement singleton pattern and the second reason is missed by an oversight.

How to implement it?

The implementation below will be subdivided into two steps addressing the 2 abovementioned primary need stepwise.

Need #1: Keeping at most one single instance

The code below is simple version of singleton pattern to address the first need above. So, the  implementation will allow us to keep at most one single the instance of our class.  

using System;

public class ProperSingleton1
{
    private static ProperSingleton1 _instance;

    public ProperSingleton1 Instance
    {
        get
        {
            if(_instance == null)
            _instance = new ProperSingleton1();

            return _instance;
        }
    }

    public void TargetMethod()
    {
        Console.WriteLine ("Target method executed");
    }
}
This implementation will run with no problem unless there is no more than one thread calling the TargetMethod.  The existence of no more than single client of TargetMethod will prevent race conditions.  If there are concurrent threads calling TargetMethod, the class must be tweaked to address thread safety issues as shown in the second step below.
 

Note: The class itself can also be defined as static, i.e. public static class ProperSingleton1.  However, if the class is defined as static then all properties and methods in the class also must have been declared as static.

Need #2: Thread safety and handling concurrency issues

What if the following race condition occured:  Thread A is switched when it is just about to initialize the variable _instance, and Thread B initialized until it is switched.  So when ot comes to Thread A again, the _instance will be instantiated again, which violates the primary reason to use Singleton pattern.
 
The solution for this race condition is implementing double-checked lock as follows.
using System;

public class ProperSingleton2
{
    private static ProperSingleton2 _instance;

    private double _someField = 0.0;
    private static readonly object _mutexObj = new object();

    public ProperSingleton2 Instance
    {
        get
        {
            if(_instance == null)//first check 
            {
                lock(_mutexObj) // lock
                {
                    if(_instance == null) // second check
                        _instance = new ProperSingleton2();
                }
            }

            return _instance;
        }
    }

    public void TargetMethod()
    {
        Console.WriteLine ("Target method executed");
    }
}
This implementation will prevent unintended second instantiation of class.  However, this is not the proper way of implementation addressing the need for thread safety, yet.  There is one more subtle but critical issue to consider.  It is volatile keyword.
 
The problem, now, is that the write/read operations is not sequentially consistent.  The compiler may perform some unintended optimisations.  For example, instantiation of a class may be considered to compromise two basic steps such as instantiation of fields and instantiation of class reference.  As an optimization, the class reference may be initialized first, before the initialization of the fields of the class.  And these two steps are not atomic.  So,
  • Thread A, has just initialized the _instance variable and is about to initialize the fields of class, 
  • Thread B may have read the non-null reference of the _instance variable (since it is located in shared memory location by definition of static) and conclude that the _instance variable has already been intialized completely. The second thread will fail when it happens to access the fields of _instance before they are actually initialized. 
This problem is resolved by defining _instance variable as volatile as follows.  Now, the compiler will guarantee the order of read/write operations as expected by means of inserting some memory barriers.  You can find more information here about the details of memory barriers.
using System;

public class ProperSingleton3
{
    private static volatile ProperSingleton3 _instance;

    private double _someField = 0.0;
    private static readonly object _mutexObj = new object();

    
    public ProperSingleton3 Instance
    {
        get
        {
            if(_instance == null)//first check 
            {
                lock(_mutexObj) // lock
                {
                    if(_instance == null) // second check
                        _instance = new ProperSingleton3();
                }
            }

            return _instance;
        }
    }

    public void TargetMethod()
    {    
        Console.WriteLine ("Target method executed");
    }
}

More optimization

Checking the volatile variable is more expensive than checking local variable namely tmpInstance.  So we can assign the value of volatile variable _instance to a local variable tmpInstance and perform the necessary checks on the local variable.  As a consequence, Joshua Bloch claims that there is %25 improvement on performance of his Java implementation on his book “Effective Java, Second Edition”.
using System;

public class ProperSingleton4
{
    private static volatile ProperSingleton4 _instance;
    private double _someField = 0.0;
    private static readonly object _mutexObj = new object();
    public ProperSingleton4 Instance
    {
        get
        {
            ProperSingleton4 tmpInstance = _instance;

            if(tmpInstance == null)//first check 
            {
                lock(_mutexObj) // lock
                {
                    tmpInstance = _instance;

                    if(tmpInstance == null) // second check
                    {
                        _instance = new ProperSingleton3();
                        tmpInstance = _instance;
                    }
                }
            }
            return tmpInstance;
        }
    }
    public void TargetMethod()
    {
        Console.WriteLine ("Target method executed");
    }
}


.net Tips

When implementing double checked lock the volatile keyword is necessary before .net 2.0 but unnecessary in .net 2.0 and later.  In .net 4.0 and later, the generic class Lazy is also another option to use since it implements double-checked lock internally. 

    using System;
    public class ProperSingleton5
    {
        private static readonly Lazy _instance = 
             new Lazy(() => new ProperSingleton5());
        private double _someField = 0.0;
        public ProperSingleton5 Instance 
        { 
            get 
            { 
                return _instance.Value; 
            } 
        } 
        
        public void TargetMethod() 
        { 
            Console.WriteLine("Target method executed"); 
        }
    }

Further references

  1. Double-checked locking | Wikipedia
  2. Memory Model, Memory Barrier and Singleton Pattern in .NET
  3. Understand the Impact of Low-Lock Techniques in Multithreaded Apps
  4. Effective Java (2nd Edition)

What is the difference between ToUpper() and ToUpperInvariant() methods of String class in .Net.

The String class has two methods called ToUpper() and ToUpperInvariant().  What are their differences and when to use which one?

ToUpper() method convert all chars to uppercase by leveraging casing conventions of “current culture”.

ToUpperInvariant() methods does the same job as ToUpper() by leveraging casing convention of “invariant culture”. So it produces the same result for any system regardless of the user’s current culture.  Therefore, when comparing the system identifiers, i.e. file names, paths, etc., normalizing the identifiers with ToUpperInvariant() is the right choice.

So the next question is … What culture does ToUpperInvariant() uses?

Below are the decompiled code of the methods inside System.String class.

public string ToUpper()
{
      return this.ToUpper(CultureInfo.CurrentCulture);
}
public string ToUpperInvariant()
{
      return this.ToUpper(CultureInfo.InvariantCulture);
}

By the way… What is the InvariantCulture?

The short answer is it is a common culture that can be used regardless of user’s country and language.

The detailed answer is clearly explained in “Using the InvariantCulture Property” and “Performing Culture-Insensitive String Operations”.

To sum up, as a general best practice, ToUpper() should be called when handling user generated strings while ToUpperInvariant should be called when handling system resources such as filenames and uri’s.

Recipe: How to make use of intellisense feature when coding JavaScript in Visual Studio 2010

Motivation

You have included a JavaScript library and you want to make use of intellisense while coding JavaScript in Visual Studio but you couldn’t find the correct way for it.

Recipe

Ingredients

  • 1 JavaScript library to include (i.e. jslinq.js)
  • 1 -vsdoc.js file of library you want to include (i.e. jslinq-vsdoc.js)

Directions

  • Include the -vsdoc.js file. You don’t need to include it in the same folder where your actual .js file is located.  However, it is more practical to keep them as close as possible for the ease of maintenance, code navigation and delightful presentation 🙂

image

  • Put the following code at the top of the JavaScript file (i.e. map.js) where you call functions of the included library (i.e. JSLINQ.js).
/// <reference path="~/Scripts/jslinq/JSLINQ-vsdoc.js" />

Tip of the recipe

    • This “<reference … /> codes” must be the first code in you calling JavaScript file (i.e. map.js)
    • The referenced path must be the path of –vsdoc.js file. Not the path of the actual js file !

 

  • Create an object of the library.

image

Tip of the recipe

  • If you create in the wrong way, although you can still use the object as expected, the intellisense won’t work.
  • Now you can make use of intellisense while you code JavaScript.

image

  • That’s it enjoy your code 🙂

The nitty gritty of primitive data types in .NET

The C# Language Specification 4.0 indicates that

C# provides a set of predefined struct types called the simple types. The simple types are identified through reserved words, but these reserved words are simply aliases for predefined struct types in the System namespace, as described in the table below.

image

So far so good.

However, when we uncover the struct definition of Int32 by means of disassembler we quickly figure out that it has a field of the type int, namely m_value.
namespace System
{
    public struct Int32
    {
        internal int m_value;
    }

}
So this seems to be a bizarre cyclic definition.  In addition, the field m_value is never accessed neither get nor set accessors.

The question is how this happens and how exactly the primitive types store their values? 

Answer:

(Below is just my interpretation for this question after digging some relevant specification documents.  The exact answer may differ to some degree)

Let’s analyze the CIL code that is generated by the following C# code.

static int Main(string[] args)
{
            //case 1: ordinary parameter names
            int paramInt = 0xABCD;
            Int32 paramInt32 = 0x1234;

            //case 2: parameter names are identical to keywords
            int int32 = 0xDCBA;
            Int32 Int32 = 0x4321;

            //all parameters are used just to suppress compiler optimization
            return paramInt + paramInt32 + int32 + Int32;
}

image

What can be seen in CIL code that both int’s and Int32’s are converted to clr type int32 (See Table I.1 in Built-in value and reference types header of CLI Specification 6th Edition).

So when compiling, the conversion is not

                                 int->Int32->int32

but rather it is

                                 int->int32

                                 Int32->int32

.

So the cycle is broken by converting simple types directly to the CLI types when compiling.  The CLI code of System.Int32 struct is generated with a field of CLI type int32 which is perfectly valid.

image

Since the 4-byte field m_value is the first and only field, m_value is aligned directly with the whole value of the 4-byte struct Int32 in the corresponding memory location.  That’s why there is no get/set accessors of m_value in the struct Int32. The same explanation can be applied to all other primitive data types in .NET.

Acknowledgements: I would like to thank to the members of Joel on Software Discussion Community for sharing their knowledge under this post.

The difference between space requirement of NULL string and EMPTY string

The Common Language Infrastructure Specification (6th Edition / June 2012), describes how string is physically stored as follows:

 

image

If the parameter kind is string, (middle line in above diagram) then the blob contains a SerString – a PackedLen count of bytes, followed by the UTF8 characters. If the string is null, its PackedLen has the value 0xFF (with no following characters). If the string is empty (“”), then PackedLen has the value 0x00 (with no following characters). (Page 294)

So, by definition, it can be concluded that null string occupies exactly the same space as empty string. 

As another case, this blog post compares the size of two tables in SQL Server with full of nulls and empty strings relatively. It proves that null string and empty string requires exactly the same size on disk. 

In conclusion, it is likely that both CLI and SQL Server implements the same logic to store string physically.