Re: [boost] [Boost.utility]

Subject: Re: [boost] [Boost.utility]
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-01-26 17:56:07

For what it's worth I faced the issue of singletons in the serialization 
library.

I wanted a system which didn't require dragging in a multi-threaded library
but I also wanted a system which would be thread-safe.  I looked around
quite a bit.  Just at that time, a singleton library was accepted for 
review.
>From what I remember it was much more complete, documentation,
examples, addressing of thread issues etc.  I resolved to wait to
see if that library was accepted.  It was not accepted.

I made a singleton library along the lines of that being suggested
here.  That library can be found in the documentation for
the serialization library. The implemenation is a template which
generates a singleton from any given class.  It has two
accessor functions:

T & get_instance()

and

const T & get_const_instance()

My ideas was that if one wanted in add thread locking somewhere
it could well be in the class T.  In any case, since all my usages
were constructed before main is called and then
there was no locking required.  (I tweaked the library to
achieve this).  So this worked well for me.  Header only
and very useful.

But for one fly in the ointment.  If a singleton is used inside
a DLL, the constructor is invoked when the dll is loaded.  If
the DLL is loaded explicitly with something like "LoadDLL"
from multiple threads then it would be a problem.  Also,
the "singleton" aspect is local to the execution module.  That
is, if the singleton is used in both the DLL and the main module
there are two "singletons" created - so they're really not singletons
any more.  Maybe they have to be called "moduletons".  Anyway
just wanted to illustrate their is a lot of history/bagage/whatever
associated with this topic and it's not going to be easy to
reach a concensus on something like this.

Robert Ramey