I'm using Windows XP / Visual C++ 2008.
I've run into a C++ static initialization order problem, which I've solved with the well-known "construct on first use" idiom:
Foo foo; // Forget this
Foo &foo() // Do this instead
{
// Use ptr, not reference, to avoid destruction order problems
static Foo *ptr = new Foo();
return *ptr;
}
However, I've been searching around and it appears that Windows (my platform) does not guarantee thread-safety of local statics, though it does make this guarantee for global statics.
So, if I make my object global, I get thread safety but I have initialization order problems. If I use "construct on first use", I avoid initialization order problems but I get race conditions. How can I solve both problems simultaneously?
In C++ 2011 you use std::call_once():
#include <mutex>
void initialize(Foo*& ptr)
{
ptr = new Foo();
}
std::once_flag flag
Foo& foo()
{
static Foo* ptr(0);
std::call_once(flag, initialize, std::ref(ptr));
return *ptr;
}
If you can't use C++2011 you might want to look at system's underlying facilities instead. For POSIX this would be pthread_once(). How this is done on other platform I don't know.
That said, I recommend not to use this because it is essentially some form of global data and there is generally no good reason to use this. There are exceptions but they are rare. Extremely rare, actually.
As you're on windows you can use a critical section. This only allows one thread to be running in the section of code after 'lock' is constructed and before it destructs - which is after foo has been initialized and before the function returns.
#include <atlbase.h>
CComAutoCriticalSection fooCs;
Foo& GetFoo()
{
CComCritSecLock<CComAutoCriticalSection> lock(cs);
static Foo foo;
return foo;
}
Don't use global variables, nor singletons, and you won't have these problems.
Related
I've created all singletons in my program with that document in mind:
http://erdani.com/publications/DDJ_Jul_Aug_2004_revised.pdf
(in case anyone wondered why singleton, all of them are factories and some of them store some global settings concerning how they should create instances).
Each of them looks somehow like this:
declaration:
class SingletonAndFactory {
static SingletonAndFactory* volatile instance;
public:
static SingletonAndFactory& getInstance();
private:
SingletonAndFactory();
SingletonAndFactory(
const SingletonAndFactory& ingletonFactory
);
~SingletonAndFactory();
};
definition:
boost::mutex singletonAndFactoryMutex;
////////////////////////////////////////////////////////////////////////////////
// class SingletonAndFactory {
SingletonAndFactory* volatile singletonAndFactory::instance = 0;
// public:
SingletonAndFactory& SingletonAndFactory::getInstance() {
// Singleton implemented according to:
// "C++ and the Perils of Double-Checked Locking".
if (!instance) {
boost::mutex::scoped_lock lock(SingletonAndFactoryMutex);
if (!instance) {
SingletonAndFactory* volatile tmp = (SingletonAndFactory*) malloc(sizeof(SingletonAndFactory));
new (tmp) SingletonAndFactory; // placement new
instance = tmp;
}
}
return *instance;
}
// private:
SingletonAndFactory::SingletonAndFactory() {}
// };
Putting aside question what design of singleton is the best (since it would start a pointless flame war) my question is: would it benefit me to replace normal pointer with std::unique_ptr? In particular, would it call singleton's destructor on program exit? If so how would I achieve it? When I tried to add something like friend class std::unique_ptr<SingletonAndFactory>; it didn't worked out since compiler keep on complaining that the destructor is private.
I know it doesn't matter in my current project since none of factories have something that would require cleaning of any sort, but for future reference I would like to know how to implement such behavior.
It's not the unique_ptr itself that does the deletion, it's the deleter. So if you wanted to go with the friend approach, you'd have to do this:
friend std::unique_ptr<SingletonFactory>::deleter_type;
However, I don't think it's guaranteed that the default deleter will not delegate the actual delete to another function, which would break this.
Instead, you might want to supply your own deleter, perhaps like this:
class SingletonFactory {
static std::unique_ptr<SingletonFactory, void (*)(SingletonFactory*)> volatile instance;
public:
static SingletonFactory& getInstance();
private:
SingletonFactory();
SingletonFactory(
const SingletonFactory& ingletonFactory
);
~SingletonFactory();
void deleter(SingletonFactory *d) { d->~SingletonFactory(); free(d); }
};
And in the creation function:
SingletonFactory* volatile tmp = (SingletonFactory*) malloc(sizeof(SingletonFactory));
new (tmp) SingletonFactory; // placement new
instance = decltype(instance)(tmp, &deleter);
In C++11, you can guarantee thread-safe lazy initialisation and destruction at the end of the program using a local static:
SingletonAndFactory& SingletonAndFactory::getInstance() {
static SingletonAndFactory instance;
return instance;
}
Beware that this can still cause lifetime issues, as it may be destroyed before other static objects. If they try to access it from their destructors, then you'll be in trouble.
Before that, it was impossible (although the above was guaranteed by many compilers). As described in the document you link to, volatile has nothing to do with thread synchronisation, so your code has a data race and undefined behaviour. Options are:
Take the (potentially large) performance hit of locking to check the pointer
Use whatever non-portable atomic intrinsics your compiler provides to test the pointer
Forget about thread-safe initialisation, and make sure it's initialised before you start your threads
Don't use singletons
I favour the last option, since it solves all the other problems introduced by the Singleton anti-pattern.
I've come across a threading issue within some code I'm working on.
MyStruct gets constructed on multiple threads which causes the program to sometimes crash within staticFunc. Big surprise as the code is accessing an unsafe variable value (MSVC 2012 compiler).
struct MyStruct : baseClass
{
MyStruct() : baseClass(myFunc())
{
}
static int* myFunc()
{
static int value[const_size] = get_array();
// Do some complex stuff to value.
return &value[0];
}
};
My question is, what is the best way to solve this?
My first thought would be to remove the static declarations all together.
This actually allowed the unit tests I wrote to pass.
struct MyStruct : baseClass
{
MyStruct() : baseClass(myFunc())
{
}
int* myFunc()
{
this->value = get_array();
// Do some complex stuff to value.
return &this->value[0];
}
int value[const_size];
};
But I'm concerned, isn't it undefined behavior if value is used before constructed/initialized?
Construction order:
baseClass constructor calls myFunc()
myFunc() uses value.
WAIT! value has not been initialized by MyStruct's constructor yet!
Is this what is happening or am i missing something and if so, what would be the correct way of solving this? static mutex?
Edit: I am using MSVC 2012(static is NOT thread safe) and moving to a different compiler is NOT an option.
The first question is whether you want to share the value between different thread or whether it is ok for each thread to store its own value.
If you want to share the value across threads you will need to protect all access with a Critical Section.
If you are ok with different threads holding different values, you will need to look at thread local storage. c++11 provides the thread_local for this purpose but I am not sure if MSVC supports this. Otherwise you can use TlsAlloc, TlsGetValue, TlsSetValue and TlsFree.
Use std::call_once, it was literally invented to solve this problem. From memory you don't need thread-safe statics for file-scope statics as they must be initialized prior to main being entered, so there's no chance of anybody having any threads in your code before it's initialized.
// Place the func_flag at file scope.
static std::once_flag my_func_flag;
class blah {
static const int* myFunc()
{
static int value[const_size];
std::call_once(my_func_flag, [] {
// perform ALL mutations of value in here.
value = get_array();
});
// Read-only from here on.
return &value[0];
}
};
If I have a private member of a class which may be modified by a background thread, and a getter for said private member, can I use a const reference to that private member for the getter or must I protect the getter with a mutex to ensure safety? Here is some example code. Note that I am not using C++11 so I do not have access to those features. I am aware of std::atomic and std::lock_guard and their uses but the code I am working on at this moment uses C++03.
It is worth noting that shared_member's type int is more of a placeholder for simplicity
If there is a nicer way to ensure safety than the get_copyof_shared_int() method, I am all ears. However if the reference will be safe that will also work, I only want to ensure safety.
#include <pthread.h>
using namespace std;
class testclass{
public:
// return reference to shared_member (provided only as example of ideal getter)
inline const int& get_shared_member () const{
return shared_member;
}
// return copy of shared_member (example of getter known to be thread safe )
inline const int get_copyof_shared_int () {
pthread_mutex_lock(&shared_int_mutex);
int shared_member_copy = shared_member;
pthread_mutex_unlock(&shared_int_mutex);
return shared_member_copy;
}
// initializes shared_member and mutex, starts running background_thread
void init(int);
private:
volatile int shared_member; //should be marked volatile because it is used in background_thread()
pthread_mutex_t shared_int_mutex;
// thread which may modify shared_member
static void *background_thread(void *arg);
};
Unfortunately yes, technically you should protect the getter since int operations are not guaranteed to be atomic.
As for the getter, it looks about as simple as it gets, although I'm not sure why you have two different getters.
EDIT: Don't forget to mark your shared variable as volatile as pointed out in the link above. Otherwise the optimizing compiler may make some improper optimizations since it can assume (wrongly in your case) the variable won't be set by another thread.
Taking a reference to it is essentially like passing a pointer (references are usually implemented as a contractual layer over pointers).
That means there is no guarantee that your thread won't read the value at some inconvenient time such as when the other thread, on a different core, is in the middle of writing to it.
Also, you might want to look into C++1's and headers.
I would also advise against inlining a getter with a mutex.
const int get_copyof_shared_int () {
std::lock_guard<std::mutex> lock(shared_int_mutex);
return shared_int;
}
I have such singleton structure:
// Hpp
class Root : public boost::noncopyable
{
public:
~Root();
static Root &Get();
void Initialize();
void Deinitialize();
private:
Root(); // Private for singleton purposes
static Root *mInstance;
Manager1 *mManager1;
Manager2 *mManager2;
};
// Cpp
Root *Root::mInstance = nullptr;
Root::Root()
{
mInstance = this;
// Managers are using `mInstance` in their constructors
mManager1 = new Manager1();
mManager2 = new Manager2();
mInstance->Initialize();
}
Root::~Root() { delete mManager1; delete mManager2; }
Root &Root::Get()
{
if (mInstance == nullptr) mInstance = new Root();
return *mInstance;
}
void Root::Deinitialize()
{
delete mInstance;
}
And here is the usage of this singleton:
Root::Get();
// Some code calling related to mManager1 and mManager2
Root::Get().Deinitialize();
The questions are:
This is memory safely to use such singleton structure?
How can I automate deletion of mInstance (call dtor manually). Because the user could forget to call Deinitialize() method.
For a single-threaded application where the singleton isn't accessed after exiting main() you can use a fairly simple approach which does everything automatically:
Root& Root::get() {
static std::unique_ptr<Root> rc(new Root());
return *rc;
}
The static in this context means that the variable is initialized the first time the function is called and then stays put. The C++ run-time arranges for the static variable rc to be destroyed at some point. For multi-threaded appplications where threads are started before entering main() you need a different approach which makes sure that the static variable is initialized only by on thread.
That said, please note that I strongly recommend not to employ the anti-pattern Singleton (also known as Global Data). The above code sample doesn't constitute a recommendation of any sort! There are few valid uses where you want to use a singleton, most uses are not. All valid uses I have seen use an immutable Singleton. Mutable singleton objects tend to become a synchronization point and tend to obfuscate the use data as global data does.
If you aren't using Visual Studio or C++11, you won't have a unique_ptr<>. In that case, you should stick with boost::scoped_ptr.hpp, since std::auto_ptr will soon be completely deprecated.
#include <boost/scoped_ptr.hpp>
#include <iostream>
class Foo {
Foo() { std::cout << "constructor" << std::endl; }
public:
static Foo& Get() {
static boost::scoped_ptr<Foo> ptr(new Foo);
return *ptr;
}
~Foo() { std::cout << "destructor" << std::endl; }
};
int main() {
Foo& f = Foo::Get();
// f is now valid until the program exits.
//Then it is destroyed before the program finishes exiting.
std::cout << "Work here" << std::endl;
}
Or you can write your own simplified scoped_ptr.
template<typename _T>
class scoped_ptr {
_T* const mPtr;
public:
scoped_ptr(_T* const t) : mPtr(t) {}
~scoped_ptr() { delete mPtr; }
operator _T* () { return const_cast<_T*>(mPtr); }
// add more operators like -> if you want them
};
Have you considered what would happened if your singleton wasn't deleted at all?
By definition, a singleton is an single object shared by many client objects as the clients tend to come and go. Most of the time your singleton will live as long as your process.
When your process shuts down, OS will reclaim most resources (memory, file handles, sockets...) and it is perfectly normal to allocate that singleton and then just let it die. This would be my recommendation.
The code is simpler. Less function calls, less complexity. No need to consider when terminate should be called and that's what brought you here.
With explicit cleanup, as your application becomes more complex (and they tend to as you keep adding features), you introduce the risk that some other object will attempt to access singleton reference after it was terminated and destroyed. Now instead of harmless memory leak which gets wiped up by the OS immediately, you have an ugly unhandled exception dialog that your users get to look at.
It is also a good practice to put Initialize() function for the singleton inside GetInstance() (as pdillon3 demonstrated) instead of having your application explicitly call Initialize(). You didn't specify this part, and if your project is an executable, you should be ok with existing design. But just be careful if you put this code inside a DLL. Some people assume DllMain is a good place to initialize singleton objects and it's not. During DllMain, loader lock global critical section is locked and singleton initializations tend to cause all kinds of trouble.
Plus now instead of 3 methods in your singleton interface, you are down to just one: GetInstance(), nice and simple.
Lastly, as Dietmar mentioned (although I still consider Singleton to be a pattern, not an anti-pattern and GoF agree with me), you should really consider whether or not you actually need a singleton. I use them from time to time, but only when I have no choice, not because they are convenient. They really are a design pattern of last resort when alternative is even more evil. Don't use them just because they are convenient.
As Scott Meyers and Andrei Alexandrescu outlined in this article the simple try to implement the double-check locking implementation is unsafe in C++ specifically and in general on multi-processor systems without using memory barriers.
I was thinking a little bit about that and came to a solution that avoids using memory barriers and should also work 100% safe in C++. The trick is to store a copy of the pointer to the instance thread-local so each thread has to acquire the lock for the first times it access the singleton.
Here is a little sample code (syntax not checked; I used pthread but all other threading libs could be used):
class Foo
{
private:
Helper *helper;
pthread_key_t localHelper;
pthread_mutex_t mutex;
public:
Foo()
: helper(NULL)
{
pthread_key_create(&localHelper, NULL);
pthread_mutex_init(&mutex);
}
~Foo()
{
pthread_key_delete(&localHelper);
pthread_mutex_destroy(&mutex);
}
Helper *getHelper()
{
Helper *res = pthread_getspecific(localHelper);
if (res == NULL)
{
pthread_mutex_lock(&mutex);
if (helper == NULL)
{
helper = new Helper();
}
res = helper;
pthread_mutex_unlock(&mutex);
pthread_setspecific(localHelper, res);
}
return res;
}
};
What are your comments/opinions?
Do you find any flaws in the idea or the implementation?
EDIT:
Helper is the type of the singleton object (I know the name is not the bet...I took it from the Java examples in the Wikipedia article about DCLP).
Foo is the Singleton container.
EDIT 2:
Because it seems to be a little bit misunderstanding that Foo is not a static class and how it is used, here an example of the usage:
static Foo foo;
.
.
.
foo.getHelper()->doSomething();
.
.
.
The reason that Foo's members are not static is simply that I was able to create/destroy the mutex and the TLS in the constructor/destructor.
If a RAII version of a C++ mutex / TLS class is used Foo can easily be switched to be static.
You seem to be calling:
pthread_mutex_init(&mutex);
...in the Helper() constructor. But that constructor is itself called in the function getHelper() (which should be static, I think) which uses the mutex. So the mutex appears to be initialised twice or not at all.
I find the code very confusing, I must say. Double-checked locking is not that complex. Why don't you start again, and this time create a Mutex class, which does the initialisation, and uses RAI to release the underlying pthread mutex? Then use this Mutex class to implement your locking.
This isn't the double-checked locking pattern. Most of the potential thread safety issues of the pattern are due to the fact the the a common state is read outside of a mutually exclusive lock, and then re-checked inside it.
What you are doing is checking a thread local data item, and then checking the common state inside a lock. This is more like a standard single check singleton pattern with a thread local cached value optimization.
To a casual glance it does look safe, though.
Looks interesting! Clever use of thread-local storage to reduce contention.
But I wonder if this is really different from the problematic approach outlined by Meyers/Alexandrescu...?
Say you have two threads for which the singleton is uninitialized (e.g. thread local slot is empty) and they run getHelper in parallel.
Won't they get into the same race over the helper member? You're still calling operator new and you're still assigning that to a member, so the risk of rogue reordering is still there, right?
EDIT: Ah, I see now. The lock is taken around the NULL-check, so it should be safe. The thread-local replaces the "first" NULL-check of the DCLP.
Obviously a few people are misunderstanding your intent/solution. Something to think about.
I think the real question to be asked is this:
Is calling pthread_getspecific() cheaper than a memory barrier?
Are you trying to make a thread-safe singleton or, implement Meyers & Andrescu's tips? The most straightforward thing is to use a
pthread_once
as is done below. Obviously you're not going for lock-free speed or anything, creating & destroying mutexes as you are so, the code may as well be simple and clear - this is the kind of thing pthread_once was made for. Note, the Helper ptr is static, otherwise it'd be harder to guarantee that there's only one Helper object:
// Foo.h
#include <pthread.h>
class Helper {};
class Foo
{
private:
static Helper* s_pTheHelper;
static ::pthread_once_t once_control;
private:
static void createHelper() { s_pTheHelper = new Helper(); }
public:
Foo()
{ // stuff
}
~Foo()
{ // stuff
}
static Helper* getInstance()
{
::pthread_once(&once_control, Foo::createHelper);
return s_pTheHelper;
}
};
// Foo.cpp
// ..
Helper* Foo::s_pTheHelper = NULL;
::pthread_once_t Foo::once_control = PTHREAD_ONCE_INIT;
// ..