Re: [boost] Boost threadsafe singleton? - Inclusion in Boost

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-08-21 12:07:54

Robert Ramey wrote:
> 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.

Yes, a brief tutorial is needed (figuring from a question on the usage I 
received via email).

I'm thinking about a text with some simple code snippets for "here's how 
to basically use it", "you might use multiple inheritance to make some 
existing class a singleton", and "you might use non-public inheritance 
to create a purely static interface".

> 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.

Well, my implementation has been uploaded just a few weeks ago. Anyway 
we might as well just request formal review - and, as the crowdedness 
has lightened, it won't take that long, especially if you volunteer to 
manage that review ;-).

> 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)

AFAICT, our "lightweight toolbox" is still insufficient to implement a 
thread-safe Singleton - I might be missing something, though. How would 
you initialize 'lightweight_mutex' when you can't know that ctors are 
run in static context (as within a shared library)?

Maybe it's possible to make 'detail::atomic_count' an aggregate and 
provide a macro for initialization (just as pthread does for its 
synchronization primitives). Then it would be trivial to implement a 
'lightweight_once' on top of it...

Thanks for your comments.

Regards,
Tobias