Re: Threadsafe singletons
David Barrett-Lennard wrote:
kanze wrote:
David Barrett-Lennard wrote:
[...]
At least some compilers, in a threaded environment, use
something like pthread_once to initialize the variable, so
constructing it before entering main isn't necessary.
Good point. I didn't know some compilers would do that.
Only some. In my opinion, it should be required, once the C++
standard recognizes threads, but there are valid arguments both
ways: a function with a static variable is inherently not thread
safe, and presumably will be used only in a single threaded
environment, or when the client code has provided higher level
protection. In such cases, there is no threading issue in the
code, and the use of something like pthread_once is extra
overhead---you're paying for something you don't use. (But I'm
still in favor of doing the right thing.)
At the other extreme, other compilers document nothing, and
may use some technique which isn't thread safe. In the
absense of any specific guarantees, I prefer to avoid
counting too much on what the compiler does here.
My own technique is basically:
static MySingleton* ourInstance = &MySingleton::instance() ;
MySingleton&
MySingleton::instance()
{
if ( ourInstance == NULL ) {
ourInstance = new MySingleton ;
}
return *ourInstance ;
}
How is it deleted?
It isn't. Generally, I don't want it to be; deleting it leads
to problems in the ordering of destructors (supposing it is used
in the destructor of an object with static lifetime).
Formally, there is no guarantee that static variables are
constructed before entering main, so you have no guaranteed
that your s_init object (or my ourInstance pointer) will be
initialized before entering main.
Really! Are you referring to the C++ standard?
Yes. In practice, you can ignore it. The standard places
certain constraints on the order of initialization if it takes
place after entering main, and those constraints are, in fact,
impossible to meet.
In practice, it will be
*UNLESS* the singleton is in a dynamically linked component.
As a general rule, I think you're safe, but only as the
consequences of a series of conditions:
-- you don't return from dlopen (or it's Windows equivalent)
before the initialization has taken place in the thread
which called dlopen, and the calling thread is guaranteed to
see the correct memory values, and
-- other threads can't know that the object has been loaded
unless you tell them, and telling them involves system
requests which synchronize memory.
In Windows if a DLL containing the definition of MySingleton
is loaded after main() begins with a call to LoadLibrary(),
then AFAIK MySingleton::GetInstance() will be called before
LoadLibrary() returns because of the static initialisation.
So the singleton is fully constructed before any attempt is
made to bind a function call to MySingleton::GetInstance().
Attention: fully constructed isn't enough. There's also a
question of memory synchronization---are other threads
guaranteed to see the version the thread which called
LoadLibrary() sees?
Under Posix (and I'm pretty sure under Windows as well), all
thread related system requests guarantee memory synchronization,
so if you use system requests to communicate the availability of
the new service to other threads, you are safe. The same may
not be true for certain lock-free algorithms.
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.
If it is mutative, and represents the correct level of
granularity for locking, another alternative is to acquire
the lock before checking for null, and to return a
boost::shared_ptr to the object, whose "destructor" frees
the lock. You need one lock anyway, this avoids a second.
I presume I misunderstand you because it seems like you will
have a problem accessing an uninitialised lock if the
singleton is accessed before main() begins.
Mutexes can be initialilzed statically, at least under Posix.
And static initialization takes place before any dynamic
initialization. Alternatively, use a singleton as above to
create the mutex. (But I really can't imagine a system where
mutexes can't be initialized statically. It sounds like a real
recepe for order of initialization problems.)
--
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! ]