Re: Threadsafe singletons
David Barrett-Lennard wrote:
There have been extensive discussions on
comp.lang.c++.moderated and comp.programming.threads about the
problem of writing a threadsafe singleton. Most of this
centers around the double checked idiom, known to be broken.
The following approach avoids the problem entirely.
Maybe. (Probably, with most implementations, in practice.
Guarantees are hard to come by, however.)
///////////// header
class MySingleton
{
public:
static MySingleton& GetInstance();
private:
MySingleton();
};
////////////// cpp
MySingleton& MySingleton::GetInstance()
{
static MySingleton s;
return s;
}
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.
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.
I've often used something similar; I've even posted about it
once or twice here. In my case, I use an explicit pointer and
new, but the principle is the same. Except that I know how an
explicit pointer and new work---I can only guess as to how the
compiler ensures creation on only the first call to GetInstance.
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. 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 ;
}
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. 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.
Pay particular attention to this second point, because it might
not hold for some 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.
--
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! ]