[boost] Boost threadsafe singleton? - Inclusion in Boost

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-20 12:37:17

I've thought about this some more and looked at the code in
you singleton as well as that of the threading library that your
code depends upon.  I'm motivated by the fact that things
are more complex that I anticipated and your package is
"boost ready" with tests, documentation, and appropriate
boost macro dependcies.

This has convinced me that I don't want to re-do any of this
and just want to depend on what you (collectively) have done.
This means biting the bullet and creating a dependency on
the thread library.  I hope whoever is maintaining the thread
library won't let me down.

Soooooooooooo,  now I've got some real serious questions.

I'm going to need a threadsafe singleton with the following
features.

a) no extra features.
b) if used in an environment which doesn't have threads,
it should compile down to almost nothing and not require
linking with the threading library.
c) good documentation - mostly done as far as I can tell.
I would like to see the singleton library have a tutorial
section showing examples in a more "chatty" style.  I'm
aware of the necessity of "formal" documentation - but
it's only really useful after one grasps the functionality
and necessity of the package in more intuitive terms.

Now assuming that the above is OK - (I can live without c)
then I have the real problem.

Suppose I want to use this to make the serialization
library threadsafe.

The singleton package is not currently in boost.  In fact,
its not even on the review schedule.  as I see it I have
a couple of options:

a) don't do anything, just wait until boost has a threadsafe
singleton.  I see no progress being made here.  Currently
there is no singleton implemenation in the review queue.

b) hack away with some ad hoc version. - built on lightweight_mutex.
Problem here is that there are no tests, no documentation, and no
promise to keep it maintained and no promise to not change the interface
in the future. (I like the size/speed and header only aspect)

c) Incorporate your threadsafe singleton as part of the
serialization library.  See the section of serializaiton library 
documentation
misc.  Which has a number of "standalone" utilities which
were need to make the serialization library work.  This could
be made to work.  Problem is that I'm going to have a huge hassle
unless its in namespace  boost::serialization::singleton  which is
pretty crazy.  Hopefully if something like this gets approved
eventually, but then I have to go back and change the namespace
reference in the serialization library.  Seems silly to me to have
to go through this.

It would also be pretty confusing as there is another
singleton in the "memory pool" library - though this one emphatically
says its not a general purpose solution.  It would also mean that
all the tests (Which MUST be run) would appear as part of the
serialization library.  This is also very confusing and in appropriate.

d) Just insert the singleton into boost/detail.  I don't like this
for the same reason I don't like depending upon 
boost/detail/lightweight/mutex:
it creates a dependency on a component which has no tests,
no documentation, and no promise to keep the interface in the future.
This is a big proble for the components that are already in there.  I run
test on utf8_codecvt facet as part of the serialization library.

As a practical matter, I'll probably just end up doing d) as it just takes
too long any other way. oh well.

Robert Ramey