How can I create a thread-safe singleton pattern in Windows?

Question

I've been reading about thread-safe singleton patterns here:

http://en.wikipedia.org/wiki/Singleton_pattern#C.2B.2B_.28using_pthreads.29

And it says at the bottom that the only safe way is to use pthread_once - which isn't available on Windows.

Is that the only way of guaranteeing thread safe initialisation?

I've read this thread on SO:

Thread safe lazy construction of a singleton in C++

And seems to hint at an atomic OS level swap and compare function, which I assume on Windows is:

http://msdn.microsoft.com/en-us/library/ms683568.aspx

Can this do what I want?

Edit: I would like lazy initialisation and for there to only ever be one instance of the class.

Someone on another site mentioned using a global inside a namespace (and he described a singleton as an anti-pattern) - how can it be an "anti-pattern"?

Accepted Answer:
I've accepted Josh's answer as I'm using Visual Studio 2008 - NB: For future readers, if you aren't using this compiler (or 2005) - Don't use the accepted answer!!

Edit: The code works fine except the return statement - I get an error: error C2440: 'return' : cannot convert from 'volatile Singleton *' to 'Singleton *'. Should I modify the return value to be volatile Singleton *?

Edit: Apparently const_cast<> will remove the volatile qualifier. Thanks again to Josh.

Answer 1

If you are are using Visual C++ 2005/2008 you can use the double checked locking pattern, since "volatile variables behave as fences". This is the most efficient way to implement a lazy-initialized singleton.

From MSDN Magazine:

Singleton* GetSingleton()
{
    volatile static Singleton* pSingleton = 0;

    if (pSingleton == NULL)
    {
        EnterCriticalSection(&cs);

        if (pSingleton == NULL)
        {
            try
            {
                pSingleton = new Singleton();
            }
            catch (...)
            {
                // Something went wrong.
            }
        }

        LeaveCriticalSection(&cs);
    }

    return const_cast<Singleton*>(pSingleton);
}

Whenever you need access to the singleton, just call GetSingleton(). The first time it is called, the static pointer will be initialized. After it's initialized, the NULL check will prevent locking for just reading the pointer.

DO NOT use this on just any compiler, as it's not portable. The standard makes no guarantees on how this will work. Visual C++ 2005 explicitly adds to the semantics of volatile to make this possible.

You'll have to declare and initialize the CRITICAL SECTION elsewhere in code. But that initialization is cheap, so lazy initialization is usually not important.

Answer 2

A simple way to guarantee cross-platform thread safe initialization of a singleton is to perform it explicitly (via a call to a static member function on the singleton) in the main thread of your application before your application starts any other threads (or at least any other threads that will access the singleton).

Ensuring thread safe access to the singleton is then achieved in the usual way with mutexes/critical sections.

Lazy initialization can also be achieved using a similar mechanism. The usual problem encountered with this is that the mutex required to provide thread-safety is often initialized in the singleton itself which just pushes the thread-safety issue to initialization of the mutex/critical section. One way to overcome this issue is to create and initialize a mutex/critical section in the main thread of your application then pass it to the singleton via a call to a static member function. The heavyweight initialization of the singleton can then occur in a thread-safe manner using this pre-initialized mutex/critical section. For example:

// A critical section guard - create on the stack to provide 
// automatic locking/unlocking even in the face of uncaught exceptions
class Guard {
    private:
        LPCRITICAL_SECTION CriticalSection;

    public:
        Guard(LPCRITICAL_SECTION CS) : CriticalSection(CS) {
            EnterCriticalSection(CriticalSection);
        }

        ~Guard() {
            LeaveCriticalSection(CriticalSection);
        }
};

// A thread-safe singleton
class Singleton {
    private:
        static Singleton* Instance;
        static CRITICAL_SECTION InitLock;
        CRITICIAL_SECTION InstanceLock;

        Singleton() {
            // Time consuming initialization here ...

            InitializeCriticalSection(&InstanceLock);
        }

        ~Singleton() {
            DeleteCriticalSection(&InstanceLock);
        }

    public:
        // Not thread-safe - to be called from the main application thread
        static void Create() {
            InitializeCriticalSection(&InitLock);
            Instance = NULL;
        }

        // Not thread-safe - to be called from the main application thread
        static void Destroy() {
            delete Instance;
            DeleteCriticalSection(&InitLock);
        }

        // Thread-safe lazy initializer
        static Singleton* GetInstance() {
            Guard(&InitLock);

            if (Instance == NULL) {
                Instance = new Singleton;
            }

            return Instance;
        }

        // Thread-safe operation
        void doThreadSafeOperation() {
            Guard(&InstanceLock);

            // Perform thread-safe operation
        }
};

However, there are good reasons to avoid the use of singletons altogether (and why they are sometimes referred to as an anti-pattern):

• They are essentially glorified global variables
• They can lead to high coupling between disparate parts of an application
• They can make unit testing more complicated or impossible (due to the difficultly in swapping real singletons with fake implementations)

An alternative is to make use of a 'logical singleton' whereby you create and initialise a single instance of a class in the main thread and pass it to the objects which require it. This approach can become unwieldy where there are many objects which you want to create as singletons. In this case the disparate objects can be bundled into a single 'Context' object which is then passed around where necessary.

Answer 3

While I like the accepted solution, I just found another promising lead and thought I should share it here: One-Time Initialization (Windows)

Answer 4

You can use an OS primitive such as mutex or critical section to ensure thread safe initialization however this will incur an overhead each time your singleton pointer is accessed (due to acquiring a lock). It's also non portable.

Answer 5

There is one clarifying point you need to consider for this question. Do you require ...

1. That one and only one instance of a class is ever actually created
2. Many instances of a class can be created but there should only be one true definitive instance of the class

There are many samples on the web to implement these patterns in C++. Here's a Code Project Sample

Answer 6

The following explains how to do it in C#, but the exact same concept applies to any programming language that would support the singleton pattern

http://www.yoda.arachsys.com/csharp/singleton.html

What you need to decide is wheter you want lazy initialization or not. Lazy initialization means that the object contained inside the singleton is created on the first call to it ex :

MySingleton::getInstance()->doWork();

if that call isnt made until later on, there is a danger of a race condition between the threads as explained in the article. However, if you put

MySingleton::getInstance()->initSingleton();

at the very beginning of your code where you assume it would be thread safe, then you are no longer lazy initializing, you will require "some" more processing power when your application starts. However it will solve a lot of headaches about race conditions if you do so.

Answer 7

If you are looking for a more portable, and easier solution, you could turn to boost.

boost::call_once can be used for thread safe initialization.

Its pretty simple to use, and will be part of the next C++0x standard.

Answer 8

The question does not require the singleton is lazy-constructed or not. Since many answers assume that, I assume that for the first phrase discuss:

Given the fact that the language itself is not thread-awareness, and plus the optimization technique, writing a portable reliable c++ singleton is very hard (if not impossible), see "C++ and the Perils of Double-Checked Locking" by Scott Meyers and Andrei Alexandrescu.

I've seen many of the answer resort to sync object on windows platform by using CriticalSection, but CriticalSection is only thread-safe when all the threads is running on one single processor, today it's probably not true.

MSDN cite: "The threads of a single process can use a critical section object for mutual-exclusion synchronization. ".

And http://msdn.microsoft.com/en-us/library/windows/desktop/ms682530(v=vs.85).aspx

clearify it further:

A critical section object provides synchronization similar to that provided by a mutex object, except that a critical section can be used only by the threads of a single process.

Now, if "lazy-constructed" is not a requirement, the following solution is both cross-module safe and thread-safe, and even portable:

struct X { };

X * get_X_Instance()
{
    static X x;
    return &x;
}
extern int X_singleton_helper = (get_X_instance(), 1);

It's cross-module-safe because we use locally-scoped static object instead of file/namespace scoped global object.

It's thread-safe because: X_singleton_helper must be assigned to the correct value before entering main or DllMain It's not lazy-constructed also because of this fact), in this expression the comma is an operator, not punctuation.

Explicitly use "extern" here to prevent compiler optimize it out(Concerns about Scott Meyers article, the big enemy is optimizer.), and also make static-analyze tool such as pc-lint keep silent. "Before main/DllMain" is Scott meyer called "single-threaded startup part" in "Effective C++ 3rd" item 4.

However, I'm not very sure about whether compiler is allowed to optimize the call the get_X_instance() out according to the language standard, please comment.

Answer 9

There are many ways to do thread safe Singleton* initialization on windows. In fact some of them are even cross-platform. In the SO thread that you linked to, they were looking for a Singleton that is lazily constructed in C, which is a bit more specific, and can be a bit trickier to do right, given the intricacies of the memory model you are working under.

• which you should never use