Re: Threadsafe singletons
kanze wrote:
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.)
I think the compiler should keep out of such concerns! Particularly
now that most compilers don't give thread safety. The cat's out of
the bag!
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).
I have never had an order of destruction problem myself. However I use
singletons rarely and they tend to be used either for caching or for
registries. Can you outline a reasonable example with order of
destruction problems?
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?
Unfortunately I doubt whether Microsoft documentation will say!
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.
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.
Note that Win32 events, mutexes, critical sections etc cannot be
initialized statically under Windows. For example, I quote from MSDN
"The process is responsible for allocating the memory used by a
critical section object, which it can do by declaring a variable of
type CRITICAL_SECTION. Before using a critical section, some thread of
the process must call the InitializeCriticalSection or
InitializeCriticalSectionAndSpinCount function to initialize the
object."
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.)
Cheers,
David Barrett-Lennard
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]