Click here to Skip to main content
Click here to Skip to main content
Go to top

Singleton Pattern: Single instance, but multiple implementations

, 27 Sep 2012
Rate this:
Please Sign up or sign in to vote.
A template based, thread safe singleton implementation in C++

Introduction

Singleton is a pattern which provides a design strategy which helps to control the instance creation of a class. It helps to maintain only a single instance (or variable instance numbers) of a class by making the constructor private and providing a instance creation function.

Singleton is a very widely used pattern. Well, at the same time it can be implemented in different ways. The pattern specification says only a single instance or a controlled number of instances can be created. If we consider a C++ version of singleton there are multiple ways we can implement the pattern. Another consideration is multithreading. We will consider the different design strategies and see how we can implement a thread safe singleton object.

The simplest design

See the below code snippet to implement a singleton.

class XMLReader
{
public:
  XMLReader& GetInstance()
  {
      static XMLReader XMLReaderObj;
      return XMLReaderObj;
  }
private:
   XMLReader(){}
};

This is the most simplest form of singleton implementation in C++. A static local object is created and its reference is returned. Since the static objects lives in the global memory, it will live till the process ends. Here we cannot control the lifetime of the object. It gets destructed when the application main returns. Suppose we need to do some cleanup before the main returns. For example we needs to save some information to a XML file. We can use an XML library like MSXML for managing XML files. This library is COM based. We initialize COM using CoInitialize or CoInitializeEx one time per thread and calls CoUninitialize before the thread returns. See the full source code for XMLWriter below.

class XMLWriter
{
public:
    static XMLWriter& GetInstance()
    {
        static XMLWriter SingletonObj;
        return SingletonObj;
    }
    bool UpdateXML(const DataHolder& DataHolderObj)
    {
       //XML updating code
    }
    ~XMLWriter()
    {
       _bstr_t bstrFileName(_T("E:\\Test.xml"));
       m_pXMLDom->save( bstrFileName );
    }
private:
    XMLWriter()
    {	
        InitDOM();
    }
    void InitDOM()
    {
        HRESULT hr = m_pXMLDom.CreateInstance(__uuidof(MSXML2::DOMDocument60));
        if (SUCCEEDED(hr))
        {
			m_pXMLDom->loadXML(       
			_bstr_t(_T("<?xml version='1.0'?>\n") 
			_T("<doc title='test'>\n")
			_T("   <page num='1'> \n") 
			_T("      <para title='Saved at last'> \n") 
			_T("          This XML data is finally saved.\n") 
			_T("      </para>\n")
			_T("   </page>\n")
			_T("   <page num='2'>\n") 
		        _T( "      <para>\n")
			_T("          This page is intentionally left blank.\n")
			_T("      </para>\n") 
			_T("   </page>\n")
			_T("</doc>\n")));

        }
    }
private:
    MSXML2::IXMLDOMDocumentPtr m_pXMLDom;
};

void main()
{
    //Initialize COM
    CoInitialize(0);
    XMLWriter& WriterObj = XMLWriter::GetInstance();
    ///some code using ReaderObj
    //...........
    CoUninitialize();
}

Certainly, this code will break the application and it will crash on exit. If we look at the destructor of XMLWriter, it is trying to save the loaded XML in to a file. But before the main returns we have uninitialized COM and the saving code needs COM environment. When the main returns the destructor gets kicked and code to save file executes. Bang!!!

We can make the call to CoInitialize in the constructor and CoUninitialize in the destructor. But in a multi threaded application, we can’t guarentee in which thread's context the object is created and so CoInitialize is called. So the CoInitialize may get called in one worker thread and CoUninitialize in the main thread(inside the destructor) as the application exits. Infact, the mainthread have not called a matching CoInitialize. This can cause undefined results. 

This is simple example to show that we need control on the destruction process. When there is nothing to be done while the object is destroyed, it is OK to use the local static object. Infact it is a threadsafe implementation. The compiler will do the necessary that a single instance of the static object is created when used in a multithreaded environment.

Now, we will look in to other strategies in singleton implementation.

Creator and Destroyer methods for finer control

See the below code snippet.

class XMLReader
{
public:
    static XMLReader& CreateInstance()
    {
        if(!m_pXMLReader)
        {           
           m_pXMLReader = new XMLReader;
        }
        return (*m_pXMLReader);
    }
    static XMLReader& GetInstance()
    {
       return (*m_pXMLReader);
    }
    static void DestroyInstance()
    {
       delete m_pXMLReader;
    }
    ~XMLReader()
    {
    }
private:
   
    XMLReader()
    {
    }

private:
    static XMLReader* m_pXMLReader;
};

This code seems OK. But what happens if memory allocation failure happens in CreateInstance. It will be returning a NULL reference if new returns NULL. If the allocation failure is returned as std::bad_alloc, CreateInstance can throw an exception, which the singleton object creation code should be aware. In the case of new returning NULL, GetInstance also return a NULL reference, which can lead to a runtime error. A modified version of this implementation is shown below. 

class XMLReader
{
public:
    static XMLReader& CreateInstance()
    {
        try
        {
            if(!m_pXMLReader)
            {
                m_pXMLReader = new XMLReader;
            }
            return (*m_pXMLReader);
        }
        catch(std::bad_alloc& baException)
        {
            throw new ObjectCreationFailed(_T("Memory allocation failed"));
        }
        catch(...)
        {
            throw new ObjectCreationFailed(_T("Unknown reason"));
        }
    }
    static XMLReader& GetInstance()
    {
        if(!m_pXMLReader)
        {
            throw new ObjectDoesNotExist;
        }
        return (*m_pXMLReader);
    }
    static void DestroyInstance()
    {
        delete m_pXMLReader;
    }
    ~XMLReader()
    {
    }
private:
    XMLReader()
    {
    }
private:
    static XMLReader* m_pXMLReader;
};

The multi threading aspects 

In above version if any error occurs in the object creation, the object itself will not be created. This is a much better one. Now, what about thread safety aspects. What happens if CreateInstance is called simultaneously by two threads? Certainly, there is a possibility of multiple instances created. This violates the assumption of singleton of only a sole instance. How can we solve this?

The solution is very common in the multithreaded environment, we need to synchronize the object creation using a critical section or mutex. We shall discuss a complete solution in the coming sections.

The usage the XMLReader class will be as shown below.

XMLReader& XMLRdrObj =
XMLReader::CreateInstance();
//use XMLReader
XMLReader::DestroyInstance();

Suppose we have multiple child threads and both needs the same singleton class. Probably, we need to call CreateInstance() from thread1 and 2 (say). Similarly, DestroyInstance before the threads end. But, how will we ensure that both threads see a valid instance always. What if thread1 ends first and thread2 continues to run? It will be catastrophic if thread1 invokes DestroyInstance and thread2 will be using an already deleted instance. This problem suggests that we need a reference counting mechanism, so that the object will be destroyed only when the final DestroyInstance is invoked. See the following implementation.

class XMLReader
{
public:
    static XMLReader& CreateInstance()
    {
        try
        {
            if(!m_pXMLReader)
            {
                m_pXMLReader = new XMLReader;
            }
            ++m_nRefCount;
            return (*m_pXMLReader);
        }
        catch(std::bad_alloc& baException)
        {
            throw new ObjectCreationFailed(_T("Memory allocation failed"));
        }
        catch(...)
        {
            throw new ObjectCreationFailed(_T("Unknown reason"));
        }
    }
    static XMLReader& GetInstance()
    {
        if(!m_pXMLReader)
        {
            throw new ObjectDoesNotExist;
        }
        return (*m_pXMLReader);
    }
    static void DestroyInstance()
    {
        --m_nRefCount;
        if(0 == m_nRefCount)
            delete m_pXMLReader;
    }
    ~XMLReader()
    {
    }
private:
    XMLReader()
    {
    }
private:
    static int m_nRefCount;
    static XMLReader* m_pXMLReader;
};

This seems much better. We have one more pending issue to be solved, a thread safe instance creation. Here I am introducing a complete solution which is a template class, that can be reused to make singleton classes.

The solution

See the code below.

/*/////////////////////////////////////////////////////////////////////////////////////
  SingletonTemplate.h - The SingletonTemplate is class which provides a generic template
  for implementing singleton pattern. This file contains the declaration/definion of the
  SingletonTemplate and its supporting classes.
 
  @written by :  Sudheesh.P.S
  @version    :  1.0            
  @date       :  26-09-2012
  @info       :  Initial version
//////////////////////////////////////////////////////////////////////////////////////*/
#pragma once

#include <exception>

/*/////////////////////////////////////////////////////////////////////////////////////
  CriticalSectionObject - A wrapper class for CRITICAL_SECTION. It manages the 
  initialization, locking, unlocking and deletion of CRITICAL_SECTION object. It is
  used by AutoCriticalSection class for automatic management of critical code areas.
//////////////////////////////////////////////////////////////////////////////////////*/
class CriticalSectionObject
{
public:
    CriticalSectionObject()
    {
        InitializeCriticalSection(&m_stCriticalSection);
    }
    void Lock()
    {
         EnterCriticalSection(&m_stCriticalSection);
    }
    void UnLock()
    {
         LeaveCriticalSection(&m_stCriticalSection);
    }
    ~CriticalSectionObject()
    {
        DeleteCriticalSection(&m_stCriticalSection);
    }
private:
    CRITICAL_SECTION m_stCriticalSection;
};

/*/////////////////////////////////////////////////////////////////////////////////////
  AutoCriticalSection - An automatic which uses the CriticalSectionSyncObj class to
  automatically lock the critical code area, by calling Lock in constructor and
  helps to leave the critical code by calling UnLock in destructor. Since it is done
  in constructor/destructor, it automatically happens.
/////////////////////////////////////////////////////////////////////////////////////*/

class AutoCriticalSection
{
public:
    AutoCriticalSection(CriticalSectionObject* pCSObj)
    {
        m_pCSObj = pCSObj;
        if( m_pCSObj  )
        {
            m_pCSObj->Lock();
        }
    }

    ~AutoCriticalSection()
    {
        if( m_pCSObj  )
        {
            m_pCSObj->UnLock();
        }
    }
private:
    CriticalSectionObject* m_pCSObj;
};

extern CriticalSectionObject g_CSObj;

/*/////////////////////////////////////////////////////////////////////////////////////
  GeneralException - A base class for exceptions
/////////////////////////////////////////////////////////////////////////////////////*/

class GeneralException
{
public:
	GeneralException(LPCTSTR lpctszDesciption)
	{
           m_ptcDescription = StrDup(lpctszDesciption);
	}
	~GeneralException()
	{
	   LocalFree(m_ptcDescription);
	}
	TCHAR* GetDescription()
	{
	   return m_ptcDescription;
	}
private:
	TCHAR* m_ptcDescription;
};

/*/////////////////////////////////////////////////////////////////////////////////////
  ObjectCreationFailedException - It is thrown when the object creation fails. This
  can be due to memory allocation failure or any other unknown cases.
/////////////////////////////////////////////////////////////////////////////////////*/

class ObjectCreationFailedException:public GeneralException
{
public:
    ObjectCreationFailedException(LPCTSTR lpctszDesciption):GeneralException(lpctszDesciption)
    {
    }
};

/*/////////////////////////////////////////////////////////////////////////////////////
  ObjectCreationFailedException - Thrown when a NULL object exist. This is a precaution
  when GetInstance is called on a destroyed instance (after DestroyInstance).
/////////////////////////////////////////////////////////////////////////////////////*/

class ObjectDoesNotExistException:public GeneralException
{
public:
    ObjectDoesNotExistException():GeneralException(_T("Object does not exist"))
    {
    }
};

/*///////////////////////////////////////////////////////////////////////////////////////
  SingletonTemplate - Singleton is a pattern which provides a design strategy which
  helps to control the instance creation of a class. It helps to maintain only a single
  instance of a class by making the constructor private and providing a CreateInstance
  function to create the class instance. The SingletonTemplate class provides a template
  class which can simplify the implementation of singleton classes. It synchronizes the
  instance creation with a critical section and also counts the reference for each 
  CreateInstance and decrements the reference for each DestroyInstance. 
  The requirements for using this class are:
  (1) - Make the constructors of target singleton class private
  (2) - Add the SingletonTemplate as friend of the target class (please sample class)
///////////////////////////////////////////////////////////////////////////////////////*/

template <class T> class SingletonTemplate 
{
public:
    /*////////////////////////////////////////////////////////////////////////////////
      Creates the instance of the singleton class. It is thread safe and keeps
      the reference count.
    ////////////////////////////////////////////////////////////////////////////////*/
    static T& CreateInstance()
    {
        try
        {
            AutoCriticalSection ACSObj(&g_CSObj);
            if( 0 == m_pTSingleInstance )
            {
                m_pTSingleInstance = new T;
            }
            ++m_nRefCount;
        }
        catch(std::bad_alloc)
        {
            throw new ObjectCreationFailedException(_T("Memory allocation failed"));
        }
        catch(...)
        {
            throw new ObjectCreationFailedException(_T("Unknown reason"));
        }
        return *m_pTSingleInstance;
    }

    /*///////////////////////////////////////////////////////////////////////////////////
      Returns the instance of the singleton class. If not exists, creates a new instance
    ///////////////////////////////////////////////////////////////////////////////////*/
    static T& GetInstance()
    {
        if( 0 == m_pTSingleInstance )
        {            
            throw new ObjectDoesNotExistException;
        }
        return *m_pTSingleInstance;
    }

    /*//////////////////////////////////////////////////////////////////////////////////
      Destroys the instance of the singleton class. It is thread safe and decrements
      the reference count. If the reference count is zero deletes the instance.
    /////////////////////////////////////////////////////////////////////////////////*/
    static void DestroyInstance()
    {
        AutoCriticalSection ACSObj(&g_CSObj);
        (m_nRefCount > 0) ? --m_nRefCount:m_nRefCount;
        if( 0 == m_nRefCount )
        {
            delete m_pTSingleInstance;
            m_pTSingleInstance = 0;
        }
    }
private:
    static T* m_pTSingleInstance;
    static int m_nRefCount;
};

template <class T> T* SingletonTemplate<T>::m_pTSingleInstance = 0;
template <class T> int SingletonTemplate<T>::m_nRefCount = 0;

The following code shows how to use SingletonTemplate class.

#pragma once

#include "SingletonTemplate.h"

class SequenceGenSingleton 
{
    friend class SingletonTemplate<SequenceGenSingleton>;
public:
    ~SequenceGenSingleton(void);
    long GetNextSeqNum();
private:
    SequenceGenSingleton(void);
    SequenceGenSingleton(int nInitVal);
private:
    long m_lSeqNum;    
};

The following code shows the usage of this class.

SingletonTemplate<SequenceGenSingleton>::CreateInstance();
SequenceGenSingleton& SingleObj = SingletonTemplate<SequenceGenSingleton>::GetInstance();
SingleObj.GetNextSeqNum();
SingletonTemplate<SequenceGenSingleton>::DestroyInstance();

The SingletonTemplate should be made the friend of the target singleton class (this gives access to the private constructor). 

DLLs and singleton  

In the case of usage from a DLL, the code can be as shown below.

BOOL WINAPI DllMain( IN HINSTANCE hDllHandle, 
         IN DWORD     dwReason, 
         IN LPVOID    lpvReserved )
 {
   switch ( dwReason )
   {
    case DLL_PROCESS_ATTACH:
	 SingletonTemplate<SequenceGenSingleton>::CreateInstance();
      break;

    case DLL_PROCESS_DETACH:
         SingletonTemplate<SequenceGenSingleton>::DestroyInstance();
      break;
   }
}

Usage from a thread 

In the case of usage from a child thread, the code can be as shown below.

DWORD WINAPI MyWorkerThread(LPVOID)
{
    SingletonTemplate<SequenceGenSingleton>::CreateInstance();
    //…………..
    //The thread code
    //…………..
    SingletonTemplate<SequenceGenSingleton>::DestroyInstance();
    return 0;
}

The thread function can have multiple return paths. So we  need to call DestroyInstance in all return paths. This gives the possibilty to define an automatic class that can automate the release process. It can be as shown below.

/*///////////////////////////////////////////////////////////////////////////////////////
  AutoSingleton - Makes the calls to CreateInstance and DestroyInstance automatic.
  This makes the usage of SingletonTemplate easy in the case of multiple return paths.
///////////////////////////////////////////////////////////////////////////////////////*/

template <class T> class AutoSingleton
{
public:
	AutoSingleton()
	{
    	   SingletonTemplate<T>::CreateInstance();
	}
	~AutoSingleton()
	{
	   SingletonTemplate<T>::DestroyInstance();
	}
};

AutoSingleton<SequenceGenSingleton> AutoSingletonObj;
SequenceGenSingleton& SingleObj = SingletonTemplate<SequenceGenSingleton>::GetInstance();

The wrapup

This is all what I have to offer now. I hope the template class provided will be useful as it takes away the need for thread synchronization and reference counting. We can make a singleton class which is thread safe just by parametrizing the SingletonTemplate with the required class and making it a friend of your class. 

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Sudheesh.P.S
Architect
India India
Working in an MNC at Bangalore. I can be reached at sudheesh_perumbilli@yahoo.com.
My personal page http://mytechcraze.wordpress.com/

Comments and Discussions

 
Question+5 PinmemberThatsAlok11-Oct-12 20:09 
AnswerRe: +5 PinmemberSudheesh.P.S13-Oct-12 7:15 
QuestionAndrei Alexandrescu: Modern C++ Design PinmemberDmitriy Iassenev3-Oct-12 7:08 
QuestionSchwarz Counter PinmemberKjellKod.cc1-Oct-12 9:27 
AnswerRe: Schwarz Counter PinmemberSudheesh.P.S4-Oct-12 6:08 
Question~ PinmemberMember 946383228-Sep-12 21:57 
AnswerRe: ~ PinmemberSudheesh.P.S4-Oct-12 5:59 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.140916.1 | Last Updated 27 Sep 2012
Article Copyright 2012 by Sudheesh.P.S
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid