Printable View
apparently the above code isn't thread-safe. even if you wrap it around with critical sections, C++ generates code for the static variable like "if not null return" stuff, and since it's in the same critical section it's possible to return a null variable when it's already initialized.Code:static T& Instance()
{
static T t;
return t;
}
is the following code thread-safe?
Code:class Foo
{
public:
static T& Instance() { return _t; }
private:
static T _t;
};
>> is the following code thread-safe?
Depends. Global object construction occurs before main(). However, other global objects can also be constructed prior to Foo which may access Foo::Instance(). Also, if the systems allows thread execution within the context of global object constructors (Windows does not) then there's the possibility of access to _t before it's been constructed.
The easiest solution is to have a "static T *pt" and initialize it to zero. The first access to pt will then always be zero. Then use synchronization to access pt - if it's zero, create your once instance.
gg
>> ... (Windows does not) ...
That's actually only for DLL's. In an EXE, global object constructors can create threads that start running immediately. In a DLL, global object constructors are performed within the context of DllMain() - which has restrictions on what you should and should not do. You can create threads, but they won't run until DllMain() returns - at which point all global objects are constructed.
gg
wow, thanks for the very informative responses.
for thread safe singletonyou have to use pthread_once
http://www.opengroup.org/onlinepubs/...read_once.html
That's a good way to do if using pthreads. Here's the most recent documentation which is a little more descriptive: http://www.opengroup.org/onlinepubs/...read_once.html
gg
I forgot:
if you are on win32, using pthread-w32, pthread_once seems broken, at least in the version I was using.
Another option should be this:
Code:
main()
{
//call singleton as long is process is single threaded
foo.instance(); //now it is initialized and ready
//spawn your threads
//call instance() from any thread
}
I simply don't understand why it's so hard to actually create the singleton at the start of main and then use the getSingleton method to access the singleton. Note that to be thread safe, the entire work on the singleton must be synchronized, not just the get method.
Or if you're really paranoid, you can guard the singleton constructor with a static variable and check if it's being instantiated more than once (in debug mode only).Code:int main()
{
mysingleton_holder singleton; // First create the singleton
mysingleton* p = singleton_holder::getsingleton(); // Now everywhere else you just use this
}
Sometimes it's nice to have a true "on-demand" singleton - where it only gets created upon first access. For instance, if the construction of the singleton implies some sort of resource acquisition/usage, then you can delay that usage until it's needed (if at all).
You may also want to remove all thread-safety responsibilities from the user - instead of requiring them to do something before creating threads.
gg
I can see the use of that, sometimes.Quote:
Originally Posted by Codeplug
But it will also incur a delay each time you would access the singleton.
Otherwise, it may be possible to use the above technique to just destroy the singleton once the program ends, since deleting singetons without hacks and trouble can be troublesome.
I always have a createInstance() and getInstance(). I've found very few, if any, ways to create exactly one singleton in a multithread environment. Even with double check locking it is possible to get two instances. The createInstance() is called once from one object and from that point on it is guaranteed to be created one time. Then getInstance() just returns that instance and does nothing else.
As long as your design follows that every singleton will be created at X time by Y object(s) and at no other time then you should be ok.
Another solution is to make the createInstance() private and then use a friend declaration for the class that is going to create or own the singleton. Friend here in this context is being used to enforce a rule of access to the function so for me it seems a valid use of it. Since createInstance() is private to everyone who is not a friend then no one else can call it w/o producing a compile time error which are my favorite types of errors. Of course someone can come behind you and just make themselves a friend but that is a clear misuse of the object in question. I do not condone the use of friend in many situations but other approaches to solve this problem frequently become more convoluted and complex than they are worth.
As for shutdown and cleanup I too have seen destroyInstance() being used but I don't like it. Singleton, to me, implies the object will be alive for the duration of the program and will be cleaned up by the compiler upon shutdown. Trying to destroy the Singleton at any other time tells me that perhaps the Singleton pattern is not what should be used for an object that requires such behavior.
Easy: don't use C++ to implement your locking mechanism.Quote:
I always have a [...] does nothing else.
And "double check locking" doesn't guarantee anything valuable with most compilers; reordering of instructions means that your code is probably broken. (I think the latest MSVC actually produces the perfect code from simple C++, but this is hearsay, I haven't looked myself.)
Soma
Easy: don't use C++ to implement your locking mechanism.Quote:
I always have a [...] does nothing else.
If you don't want to rely on a specific platform or namely any mutexes, critical sections, etc. in Windows then I have no other idea other than the one I presented to ensure only one instance is created using the standard singleton pattern in a multi-thread environment.