Re: Threadsafe singletons
David Barrett-Lennard wrote:
///////////// header
class MySingleton
{
public:
static MySingleton& GetInstance();
private:
MySingleton();
};
////////////// cpp
MySingleton& MySingleton::GetInstance()
{
static MySingleton s;
return s;
}
Is this not threadsafe anyway (assuming you have a compliant
compiler?). There should be only one instance of a static regardless of
race conditions.
static struct InitMySingleton
{
InitMySingleton() { MySingleton::GetInstance(); }
} s_init;
The GetInstance() function employs the lazy creation approach.
However, the intention is not to avoid consuming resources. In fact
the static InitMySingleton instance is used to force the singleton to
be eagerly initialized before main() begins.
Yes but then you may as well just use a static instance of MySingleton
instead. s_init has to exist of course in a compilation unit
somewhere, but why not just the MySingleton instance there?
Of course there is no way to catch any exceptions should MySingleton's
constructor throw one so you'd better make sure it doesn't.
Also, being created as an instance rather than a pointer means there is
no deterministic destruction. Assuming the destructor is trivial (and
note that trivial here doesn't just mean implicit, it means it really
deletes nothing, no members etc). you have nothing to worry about. If
it is not then there are possibilities of undefined behaviour on
destruction. You may not care if your app seg-faults when it is being
closed down anyway, but it's not really ideal behaviour.
It is assumed that no additional threads are created until after main()
begins. Therefore before main() only one thread can call
GetInstance(). Even if other static initialization code causes
GetInstance() to be called there is no threading issue. Furthermore
the lazy creation within GetInstance() ensures that the MySingleton
object is properly constructed before it is first used.
But it isn't lazy creation. Lazy creation means creating when first
required. Here it is created before main is called .Now it may be that
is the behaviour you want - after all once your app is in "full swing"
you might not be able to afford the time-delay of lazy creation whilst
you do afford the time on start-up (when no clients have yet connected
to your server). Of course that might mean you are loading resources
that are never used, but that is for you to determine.
After main() is called, threads may be created that call
GetInstance(). All threads will find that the MySingleton object has
already been fully constructed, even in a multiprocessor machine. Note
that thread creation implicitly involves the necessary memory barriers.
MySingleton can choose to use a mutex member if it is mutative.
Otherwise it may provide shared read access without any mutex at all.
Well that is now implementation detail for your class, but ask yourself
if it really does need to be a singleton. I used to use a lot of
singletons. Now I have just 2 - and that is really one too many. One of
my singletons is a collection of all the libraries that have been
opened with dlopen(), the other is there to handle signals to ensure
clean shutdown, ensure all the logs are flushed, etc. Even then the
second one uses objects that are in libraries held by the first so it
has to be "cleared" first. So one must call an implicit clear() on it
to ensure deterministic destruction.
Now what might be a better approach for you here is to have the inner
object (the singleton) be a pointer which is created by the static that
wraps it, and that be a manager for ALL your singletons Of course that
means you need to know what they all are. But it will ensure
deterministic destruction.
But now, hey, what about the issue of catching the exceptions? Well
that's simple, don't make this wrapper a static at all, make it an
instance inside your main() function.
Hey, not sure where this will lead but maybe we'll end up eliminating
pretty much all your singletons...
Cheers,
David Barrett-Lennard
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]