(Code taken from book: http://gameprogrammingpatterns.com/ by Robert Nystrom)
In the book above the author comes with two different ways of making a singleton class:
First one:
class FileSystem
{
public:
static FileSystem& instance()
{
// Lazy initialize.
if (instance_ == NULL) instance_ = new FileSystem();
return *instance_;
}
private:
FileSystem() {}
static FileSystem* instance_;
};
And second one:
class FileSystem
{
public:
static FileSystem& instance()
{
static FileSystem *instance = new FileSystem();
return *instance;
}
private:
FileSystem() {}
};
Later he states that the second one is more proper way to do this, since it is thread safe, while the first one is not.
What makes the second one thread safe?
What is the difference in static declarations between these two?
The first version is not thread-safe for multiple threads may try to read and modify instance_ concurrently without any synchronization, which leads to a race condition.
The second version is thread-safe since C++11. Quoted from cppreference (the Static local variables section):
If multiple threads attempt to initialize the same static local
variable concurrently, the initialization occurs exactly once (similar
behavior can be obtained for arbitrary functions with std::call_once)
With this guarantee, modification to instance happens only once, and there is no problem with concurrent reads.
Still, the second version is not thread-safe until C++11.
In the first code snippet setting the instance_ pointer to a singleton is an assignment. It does not get any special treatment from the compiler. In particular, it could be done multiple times if instance() is invoked from concurrent threads.
This creates a problem when two concurrent threads try evaluating instance_ == NULL, and get a true. At this point both threads create a new instance, and assign it to the instance_ variable. The first pointer assigned to instance_ is leaked, because the second thread immediately overrides it, rendering the object inaccessible.
In the second code snippet setting the instance pointer is initialization. The compiler guarantees that initialization of a static variable will be done at most once, regardless of the number of threads that invoke instance() concurrently. Essentially, the guarantee that there is at most one singleton in the system is provided by the compiler, without any explicit code for handling concurrency.
In former case, if two threads try to create the instance at the same time, 2 (or more) copies of singleton objects might be created. (if **instance_** is observed NULL by both and both create a new instance). (Even worse, thread creating first instance may get a different value of instance in subsequent calls)
While second one uses static initialization and object is constructed when the function is invoked for the first time. So it is guaranteed by the compiler that static FileSystem *instance = new FileSystem(); would be executed at most once during the lifetime of program single and thus atmist single copy of object would exist at any time.
This makes the later design thread safe for C++11 and onwards complian C++ compilers. Though the design may not be safe for in C++03 and C++98 implementation.
Another downside of former design is, the object can not be destructed while in later design it can be destructed by changing the typeof instance_ to static FileSystem. i.e.
static FileSystem& instance()
{
static FileSystem instance;
return instance;
}
Related: Is Meyers implementation of Singleton pattern thread safe?
Related
I am currently reading Effective C++. There is a section about using static local variables and it says that if multiple threads access a static variable, there may be a race condition during initialization of that variable.
At least that is my interpretation. Is this true? In C# for example, initialization of a class static variable will never have a race condition.
For example, can this code have a race condition during the static variable initialization?
FileSystem& tfs()
{
static FileSystem fs;
return fs;
}
Below is the except from the book.
Here's the technique applied to both tfs and tempDir:
class FileSystem { ... }; // as before
FileSystem& tfs() // this replaces the tfs object; it could static in the FileSystem class
{
static FileSystem fs; // define and initialize a local static object
return fs; // return a reference to it
}
.
class Directory { ... }; // as before
Directory::Directory( params ) // as before, except references to tfs are now to tfs()
{
...
std::size_t disks = tfs().numDisks();
...
}
Directory& tempDir() // this replaces the tempDir object; it could be static in the Directory class
{
static Directory td; // define/initialize local static object
return td; // return reference to it
}
Clients of this modified system program exactly as they used to,
except they now refer to tfs() and tempDir() instead of tfs and
tempDir. That is, they use functions returning references to objects
instead of using the objects themselves.
The reference-returning functions dictated by this scheme are always
simple: define and initialize a local static object on line 1, return
it on line 2. This simplicity makes them excellent candidates for
inlining, especially if they're called frequently (see Item 30). On
the other hand, the fact that these functions contain static objects
makes them problematic in multithreaded systems. Then again, any kind
of non-const static object — local or non-local — is trouble waiting
to happen in the presence of multiple threads. One way to deal with
such trouble is to manually invoke all the reference-returning
functions during the single-threaded startup portion of the program.
This eliminates initialization-related race conditions.
This section is outdated. The C++03 standard had no mention of threads, so when C++ implementations added them, they did whatever they wanted to with regards to the thread-safety of language constructs. A common choice was to not ensure thread-safe initialisation of static local variables.
In C++11, local static variables are guaranteed to be initialised exactly once, the first time that the program's control flow passes through their declaration, even if this happens concurrently on multiple threads 6.7/4:
An implementation is permitted to perform early initialization of other block-scope variables with static or thread storage duration under the same conditions that an implementation is permitted to statically initialize a variable with static or thread storage duration in namespace scope (3.6.2). Otherwise such a variable is initialized the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
Even so, this only ensures that initialisation is safe. If you plan to use the returned FileSystem from multiple threads simultaneously, FileSystem must itself provide threadsafe operations.
I have a state engine that uses a Singleton software design pattern. The state engine can be accessed by multiple threads. The object is initialized from the main thread at program start up and is not designed for Lazy initialization.
My question is, should I make the public static members volatile like this:
class CStateEngine final
{
private:
/* Contains the Singleton object */
static CStateEngine* instance;
protected:
CStateEngine();
public:
static CStateEngine* Instance() volatile; // Returns the Singleton instance
static void DeleteInstance() volatile; // Deletes the Singleton instance
}
The volatile keyword in C++ is NOT the same as in any other languages. In C++ it means that the compiler will make sure that the value is always newly read from memory, and never a cached value is used.
It has it's uses the embedded world and other places. If you wanted to have an always up to date view of a certain variable you'd mark it as volatile.
It has nothing however to do with multithreading.
You should not use a singleton in a multi-threaded environment, because it will be a cause for contention as multiple threads try to access your object. It will cause your programs to lag and it entirely defeats using threads in the first place.
You should pass objects around, and you should be able to create new ones as you need them.
If you can't do that, review your design.
I have the following sample C++ code:
class Factory
{
public:
static Factory& createInstance()
{
static Factory fac;
return fac;
}
private:
Factory()
{
//Does something non-trivial
}
};
Let's assume that createInstance is called by two threads at the same time. So will the resulting object be created properly? What happens if the second thread enters the createInstance call when the first thread is in the constructor of Factory?
C++11 and above: local static creation is thread-safe.
The standard guarantees that:
The creation is synchronized.
Should the creation throws an exception, the next time the flow of execution passes the variable definition point, creation will be attempted again.
It is generally implemented with double-checking:
first a thread-local flag is checked, and if set, then the variable is accessed.
if not yet set, then a more expensive synchronized path is taken, and if the variable is created afterward, the thread-local flag is set.
C++03 and C++98: the standard knows no thread.
There are no threads as far as the Standard is concerned, and therefore there is no provision in the Standard regarding synchronization across threads.
However some compilers implement more than the standard mandates, either in the form of extensions or by giving stronger guarantees, so check out for the compilers you're interested in. If they are good quality ones, chances are that they will guarantee it.
Finally, it might not be necessary for it to be thread-safe. If you call this method before creating any thread, then you ensures that it will be correctly initialized before the real multi-threading comes into play, and you'll neatly side-step the issue.
Looking at this page, I'd say that this is not thread-safe, because the constructor could get called multiple times before the variable is finally assigned. An InterlockedCompareExchange() might be needed, where you create a local copy of the variable, then atomically assign the pointer to a static field via the interlocked function, if the static variable is null.
Of course it's thread safe! Unless you are a complete lunatic and spawn threads from constructors of static objects, you won't have any threads until after main() is called, and the createInstance method is just returning a reference to an already constructed object, there's no way this can fail. ISO C++ guarantees that the object will be constructed before the first use after main() is called: there's no assurance that will be before main is called, but is has to be before the first use, and so all systems will perform the initialisation before main() is called. Of course ISO C++ doesn't define behaviour in the presence of threads or dynamic loading, but all compilers for host level machines provide this support and will try to preserve the semantics specified for singly threaded statically linked code where possible.
The instantiation (first call) itself is threadsafe.
However, subsequent access will not be, in general. For instance, suppose after instantiation, one thread calls a mutable Factory method and another calls some accessor method in Factory, then you will be in trouble.
For example, if your factory keeps a count of the number of instances created, you will be in trouble without some kind of mutex around that variable.
However, if Factory is truly a class with no state (no member variables), then you will be okay.
This question already has answers here:
Is Meyers' implementation of the Singleton pattern thread safe?
(6 answers)
Closed 4 years ago.
I've seen implementations of Singleton patterns where instance variable was declared as static variable in GetInstance method. Like this:
SomeBaseClass &SomeClass::GetInstance()
{
static SomeClass instance;
return instance;
}
I see following positive sides of this approach:
The code is simpler, because it's compiler who responsible for creating this object only when GetInstance called for the first time.
The code is safer, because there is no other way to get reference to instance, but with GetInstance method and there is no other way to change instance, but inside GetInstance method.
What are the negative sides of this approach (except that this is not very OOP-ish) ? Is this thread-safe?
In C++11 it is thread safe:
§6.7 [stmt.dcl] p4 If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
In C++03:
Under g++ it is thread safe.
But this is because g++ explicitly adds code to guarantee it.
One problem is that if you have two singletons and they try and use each other during construction and destruction.
Read this:
Finding C++ static initialization order problems
A variation on this problem is if the singleton is accessed from the destructor of a global variable. In this situation the singleton has definitely been destroyed, but the get method will still return a reference to the destroyed object.
There are ways around this but they are messy and not worth doing. Just don't access a singleton from the destructor of a global variable.
A Safer definition but ugly:
I am sure you can add some appropriate macros to tidy this up
SomeBaseClass &SomeClass::GetInstance()
{
#ifdef _WIN32
Start Critical Section Here
#elif defined(__GNUC__) && (__GNUC__ > 3)
// You are OK
#else
#error Add Critical Section for your platform
#endif
static SomeClass instance;
#ifdef _WIN32
END Critical Section Here
#endif
return instance;
}
It is not thread safe as shown. The C++ language is silent on threads so you have no inherent guarantees from the language. You will have to use platform synchronization primitives, e.g. Win32 ::EnterCriticalSection(), to protect access.
Your particular approach would be problematic b/c the compiler will insert some (non-thread safe) code to initialize the static instance on first invocation, most likely it will be before the function body begins execution (and hence before any synchronization can be invoked.)
Using a global/static member pointer to SomeClass and then initializing within a synchronized block would prove less problematic to implement.
#include <boost/shared_ptr.hpp>
namespace
{
//Could be implemented as private member of SomeClass instead..
boost::shared_ptr<SomeClass> g_instance;
}
SomeBaseClass &SomeClass::GetInstance()
{
//Synchronize me e.g. ::EnterCriticalSection()
if(g_instance == NULL)
g_instance = boost::shared_ptr<SomeClass>(new SomeClass());
//Unsynchronize me e.g. :::LeaveCriticalSection();
return *g_instance;
}
I haven't compiled this so it's for illustrative purposes only. It also relies on the boost library to obtain the same lifetime (or there about) as your original example. You can also use std::tr1 (C++0x).
According to specs this should also work in VC++. Anyone know if it does?
Just add keyword volatile.
The visual c++ compiler should then generate mutexes if the doc on msdn is correct.
SomeBaseClass &SomeClass::GetInstance()
{
static volatile SomeClass instance;
return instance;
}
It shares all of the common failings of Singleton implementations, namely:
It is untestable
It is not thread safe (this is trivial enough to see if you imagine two threads entering the function at the same time)
It is a memory leak
I recommend never using Singleton in any production code.
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.
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.
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.
While I like the accepted solution, I just found another promising lead and thought I should share it here: One-Time Initialization (Windows)
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.
There is one clarifying point you need to consider for this question. Do you require ...
That one and only one instance of a class is ever actually created
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
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.
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.
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.
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