Re: Singleton Pattern
On Apr 19, 11:53 pm, joshuamaur...@gmail.com wrote:
On Apr 19, 6:07 am, Keshav <gupta.kes...@gmail.com> wrote:> HI,
I would like to know whetehr this is the right way to
implement thread safe singleton. Generally we do locking
and all at Instance method, Can we get rid of these problems
if we create instance while defining pInstance variable.
Would it create any problem?
[snip]
There are 3 issues when creating a singleton in C++ that you
have to worry about:
- static initialization order fiasco (see the C++ FAQ)
- static de-initialization order fiasco (see the C++ FAQ)
- thread-safety (see any standard piece on thread safety in C++. I
strongly suggesthttp://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.p=
df
as one of the best papers on the topic.)
If you can guarantee that no other global (or namespace)
object will use your singleton, then you can ignore static
initialization order problems and static de-initialization
order problems. (This is not something you can usually safely
assumption. This is bad style to assume this as it is fragile.
Someone somewhere else can break your code with touching your
code at all. I will thus ignore this possibility here.)
Whether you can safely assume it depends on the "scope" (in the
general sense, not strictly in the language sense) of the
singleton. If the "singleton" is used only within a single
component, just making it a variable with static lifetime is
likely the preferred solution (although it does depend on the
component).
Your options are "eager-initialized initialized-on-demand
singleton" or "lazy-initialized initialized-on-demand
singleton". There are several implementations for each,
depending on the threading primitive you want to use.
An example implementation of "eager-initialized
initialized-on-demand singleton" (left as an exercise to
determine which parts go in the header and cpp). (Note that
access to the singleton itself may require a mutex. This just
guarantees a single thread-safe construction.)
class singleton_t {};
singleton_t & getSingleton()
{ static singleton_t * x = 0;
if ( ! x)
x = new singleton_t;
return *x;
}
How is that "eager"? It looks like lazy initialization to me.
/* Eager initialize the singleton to ensure it's created
before main, and thus before there are multiple threads. If
threads are created before main, then it's impossible to do
this safely in C++03.*/
namespace
{ struct EagerInitialize { EagerInitialize() { getSingleton(); } };
EagerInitialize instEagerInit;
}
That's fundamentally the same thing he's doing, except that I've
never seen anyone bother with the extra class. The two
"classical" solutions are usinge the results of instance to
initialize the pointer, and using some other "artificial"
variable, e.g.:
namespace {
bool dummyForInitialization = (Singleton::instance(), true) ;
}
An example implementation of "lazy-initialized
initialized-on-demand singleton" (left as an exercise to
determine which parts go in the header and cpp). (Note that it
contains eager-initialization initialization-on-demand of the
guarding mutex.) (Note that access to the singleton itself may
require a mutex. This just guarantees a single thread-safe
construction.)
//from threading library
class mutex {};
class guard { public: guard(mutex& ); ~guard(); };
mutex & getSingletonMutex()
{ static mutex * x = 0;
if ( ! x)
x = new mutex;
return *x;
}
/* Eager initialize mutex to ensure it's created before main,
and thus before there are multiple threads. If threads are
created before main, then it's impossible to do this safely in
C++03.*/
namespace
{ struct EagerInitialize { EagerInitialize() { getSingletonMutex
(); } };
EagerInitialize instEagerInit;
}
class singleton_t {};
singleton_t & getSingleton()
{ guard g(getSingletonMutex());
static singleton_t * x = 0;
if ( ! x)
x = new singleton_t;
return *x;
}
How does this ensure anything that his code doesn't? It still
fails if a thread which uses the singleton is started from the
constructor of a static object.
Under Unix, I frequently use a statically initialize
pthread_mutex_t for this sort of thing; as far as I know,
Windows doesn't have anything similar. Otherwise, you have to
ensure that at least one master mutex is created before
threading starts---if all threads are created by the same C++
threading library, the obvious solution is to use lazy
initialization to create the master mutex in the primitive which
creates the threads. (If all threads are created by primitives
in the library, obviously, when the first call to such a
primitive occurs, there are no other threads.)
Generally, if lazy initialization is used, the variable
controling the singleton will be local to the instance class,
e.g. either:
Singleton&
Singleton::instance()
{
ScopedLock l( mutex ) ;
static Singleton theOneAndOnly ;
return theOneAndOnly ;
}
or (more often, in my experience):
Singleton&
Singleton::instance()
{
ScopedLock l( mutex ) ;
static Singleton* theOneAndOnly = NULL ;
if ( theOneAndOnly == NULL ) {
theOneAndOnly = new Singleton ;
}
return *theOneAndOnly ;
}
(The first calls the destructor on the singleton object, with
the risk of order of destruction issues. The second never
destroys the singleton object.)
Of course, there's still the problem of constructing the mutex.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34