There are a lot of issues with the singleton pattern. I'm totally aware of that. But the singleton pattern is an ideal use case for a variable, which has only to be initialized in a thread safe way. From that point on you can use it without synchronization. So in this post I discuss different ways to initialize a singleton in a multithreading environment. You get the performance numbers and can reason about your uses cases for the thread safe initialization of a variable.

There are a lot of different ways to initialize a singleton in C++11 in a thread safe way. From a birds eye you can have guarantees from the C++ runtime, locks or atomics. I'm totally curious about the performance implications.

My strategy

I use as reference point for my performance measurement a singleton object which I sequential access 40 million times. The first access will initialize the object. In contrast, the access from the multithreading program will be done by 4 threads. Here I'm only interested in the performance. The program will run on two real PCs. My Linux PC has four, my Windows PC has two cores. I compile the program with maximum and without optimization. For the translation of the program with maximum optimization I have to use a volatile variable in the static method getInstance. If not the compiler will optimize away my access to the singleton and my program becomes to fast.

I have three questions in my mind:

How is the relative performance of the different singleton implementations?

Is there a significant difference between Linux (gcc) and Windwos (cl.exe)?

What's the difference between the optimized and non-optimized versions?

Finally, I collect all numbers in a table. The numbers are in seconds.

The reference values

The both compilers

The command line gives you the details to the compiler Here are the gcc and the cl.exe.

The reference code

At first, the single threaded case. Of course without synchronization.

I use in the reference implementation the so called Meyers Singleton. The elegance of this implementation is that the singleton object instance in line 11 is a static variable with block scope. Therefore, instance will exactly be initialized, when the static method getInstance (line 10 - 14) will be executed the first time. In line 14 the volatile variable dummy is commented out. When I translate the program with maximum optimization that has to change. So the call MySingleton::getInstance() will not be optimized away.

Now the raw numbers on Linux and Windows.

Without optimization

Maximum Optimization

Guarantees of the C++ runtime

Meyers Singleton

The beauty of the Meyers Singleton in C++11 is that it's automatically thread safe. That is guaranteed by the standard: Static variables with block scope. The Meyers Singleton is a static variable with block scope, so we are done. It's still left to rewrite the program for four threads.

I use the singleton object in the function getTime (line 24 - 32). The function is executed by the four promise in line 36 - 39. The results of the associate futures are summed up in line 41. That's all. Only the execution time is missing.

Without optimization

Maximum optimization

The next step is the function std::call_once in combination with the flag std::once_flag.

The function std::call_once and the flag std::once_flag

You can use the function std::call_onceto register a callable which will be executed exactly once. The flag std::call_once in the following implementation guarantees that the singleton will be thread safe initialized.

Without optimization

Maximum optimization

But we can do better. There is an additional optimization possibility.

Acquire-release Semantic

The reading of the singleton (line 14) is an acquire operation, the writing a release operation (line 20). Because both operations take place on the same atomic I don't need sequential consistency. The C++ standard guarantees that an acquire operation synchronizes with a release operation on the same atomic. This conditions hold in this case therefore I can weaken the C++ memory model in line 14 and 20. Acquire-release semantic is sufficient.

The acquire-release semantic has a similar performance as the sequential consistency. That's not surprising, because on x86 both memory models are very similar. We would get totally different numbers on an ARMv7 or PowerPC architecture. You can read the details on Jeff Preshings blog Preshing on Programming.

Without optimization

Maximum optimization

.

If I forget an import variant of the thread safe singleton pattern, please let me know and send me the code. I will measure it and add the numbers to the comparison.

All numbers at one glance

Don't take the numbers too seriously. I executed each program only once and the executable is optimized for four cores on my two core windows PC. But the numbers give a clear indication. The Meyers Singleton is the easiest to get and the fastest one. In particular the lock based implementation is by far the slowest one. The numbers are independent of the used platform.

But the numbers show more. Optimization counts. This statements holds not totally true for the std::lock_guard based implementation of the singleton pattern.

What's next?

I'm not so sure. This post is a the translation of german post I wrote half a year ago. My German post get's a lot of reaction. I'm not sure, what will happen this time. A few days letter I'm sure. The next post will be about the addition of the elements of a vector. First it takes in one thread.

Go to Leanpub/cpplibrary"What every professional C++ programmer should know about the C++ standard library".Get your e-book. Support my blog.

I hope I get your point. You proposing using volatile as a kind of atomi?. If so volatile has no multithreading semantic. Maybe the compiler guarantees it. With volatile we are in the area of the broken double-checked locking pattern. To measure undefined behaviours makes no sense from my perspective.

Why do you need a mutex on line 16? I know the problem with double check locking but I thought with atomics it's not the case so no need for the mutex.

Is it possible that relaxed read (line 17) move above mutex lock (line 16)? In that case this approach is also broken. Or maybe a mutex lock guarantees a happens-before relationship?

You have no guarantee that the line 19 (sin= new MySingleton()) is an atomic operation. Therefore you can have a half initialized singleton.The lock establishes a kind of a barrier. Nothing from inside can cross the border. => See the details in the post: Acquire-release semantic

Just desire to say your article iss as astounding. Thhe clarity to your submit is just nice aand that i ccan assume you're knowledgeable in this subject.Well with your permission let me tto take hod off your RSS feed too stay up to datee with imminent post. Thankk yoou one million and please keep up the gratifying work.