Re: Threadsafe singletons
Earl Purple wrote:
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.
Should is a very vague word. According to what standard? The
C++ standard says that as soon as you invoke pthread_create, or
something along those lines, you have undefined behavior. And
Posix doesn't say anything about it.
From a quality of implementation point of view, I'd say you were
right. From a practical point of view, however, most compilers
don't seem to guarantee that this function is thread safe.
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.
Or that it doesn't matter. Even programs which try to recover
from out of memory conditions punt when the condition occurs
during program start-up.
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.
The problem isn't just seg-faults. If we suppose that there
exist objects which have non-trivial destructors for reasons
other than just freeing memory (e.g. to delete a temporary
file), then they might not be called.
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.
But that isn't part of the requirements. Singleton means that
there is a unique instance---only one. Lazy creation may or may
not be a side effect of this. If lazy creation is an essential
attribute, you need something else. With a different name.
---
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]