Re: Confused about a thread-safe singleton example.
On Dec 3, 1:47 am, Alan Johnson <aw...@yahoo.com> wrote:
jason.cipri...@gmail.com wrote:
I have a C++-specific question about thread-safe singleton instances.
There's a trivial example here:
http://www.bombaydigital.com/arenared/2005/10/25/1
That goes like this, very simple and straightforward:
static Mutex mutex; static TheClass *instance;
static TheClass * getInstance () { MutexLocker lock(mutex); if
(!instance) instance = new TheClass(); return instance; }
The example then goes on to talk about how double-check locking is
broken, etc. My question is pretty much this: Is C++ static
initialization thread-safe? If not, then how does the above example
safely use "mutex"? If so, then what is wrong with this:
static TheClass instance; // not a pointer
static TheClass * getInstance () { return &instance; // it's
correctly initialized? }
The reason I ask is I almost never see it done like that, I always
see blog entries and articles that say the same thing "store instance
in a pointer, use a mutex to protect, and p.s. double-checked locking
is broken". It seems like doing it lock-free is made out to be a hard
problem, so *if* having a static instance works (but I don't know if
it does, that's my question), then why doesn't anybody ever suggest
it?
Thanks! Jason
1. Don't use singletons. Ever. Pretty much all of the value of the =
GoF
Design Patterns book is negated by the fact that they chose to
legitimize Singleton as a design pattern. Singleton is just a fancy
name for global variable. We should call it the Global Variable
(anti)Pattern.
2. If you think you've found a good reason to use a singleton, see point =
#1.
In this case, the object in question is used as a "default object"
when some other non-default object isn't explicitly used (sorry I'm
being vague, but there's not much need to explain it). Maintaining a
single instance of the "default object" eliminates the need to have to
clean up separate default object instances, and to keep track of
whether or not clean up is necessary, who owns the object, etc. It
greatly simplifies a lot of application code. And you are correct, in
this case it basically is, in fact, a global variable.
3. Double checked locking works without memory fencing on x86:http://bart=
oszmilewski.wordpress.com/2008/11/05/who-ordered-memory-fe...
Thus, your main opponent in the optimizer.
4. Whether or not the construction of a static variable is threadsafe
depends mostly on the implementation (the standard says nothing about
it). gcc has an option =fno-threadsafe-statics to turn off the extra
code emitted to make local statics thread safe. I guess one could
extrapolate that by default local statics are thread safe in gcc (though
I have no idea if this is actually true).
I think you may be talking about function-local statics. C++
guarantees that global-scoped statics are initialized before main().
This means that, as long as the singleton class initialization doesn't
depend on objects being initialized in other translation units (and
the other way around), it *will* be properly initialized before main
(), and therefore it will be properly initialized before any threads
access it (assuming all threads are created after main starts, not
during static initialization). So no locking would be needed (on any
platforms); getInstance() would always return a completely initialized
object -- here is the method I finally settled on:
=== MyClass.h ===
class MyClass {
....
static MyClass * getInstance ();
....
};
=== MyClass.cpp ===
static MyClass *instance = new MyClass();
MyClass * MyClass::getInstance () {
return instance;
}
The same appears to be true for class-scoped statics as well, but I
didn't do any more digging because the above solved the problem.
Thanks,
Jason
--
Alan Johnson