Re: [boost] Threadsafe singleton - questions

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-08-24 17:58:00

Robert Ramey wrote:
> I'm going through the documentation and now have some questions.
> I would hope that the documentation could be expanded to
> include answers to these questions.
> 
> a) reference is made to a "lease" which sounds like a mutex
> to me.  

No it is not a mutex. The 'lease' is a syntactic construct of the 
interface. Its purpose is to optain a proxy for subsequent calls.

A 'mutexed_singleton' is locked by the existence of a lease object. 
Others are not.

> But its not obvious to me how this should be used.
> How does the compare with the pattern that I am more
> familiar with
> 
> class s : singlton
>       mutex m_mutex
> ...
> 
> my_function(...){
>     scoped_lock(m_mutex);
>    ...
> }
> 
> OK - I've looked again and I think its clear to me how this
> is to be used.

OK, I'll answer, anyway. It depends on what you want to do:

If your singleton holds some data structure (e.g. a linked list) and you 
want it to be thread-safe just use 'mutexed_singleton', put a member 
(e.g. a std::list) inside it and you don't need to care about anything 
else (concurrent access is mutually exclusive).

If your use case is more complicated (e.g. you have a reader/writer 
problem or several data structures are contained that aren't touched by 
all member functions) you might want to do things yourself (e.g. using 
'read_write_mutex' or several mutexes, respectively). In this case use 
'singleton' and synchronize access to the singleton body yourself. This 
is also the right choice if the Singleton is immutable (such as extended 
type info might be). Note that the initialization is still thread-safe.

The 'thread_specific_singleton' is a different kind of beast in this 
regard, since it doesn't need much synchronization - every thread gets 
its own instance.

> We need a tutorial here !!!!

Yep, especially since you're not the first one who asks.

> b) reference is made to boost::restricted which I couldn't
> find anywhere.

That's a bit strange since it's even documented redundantly as an 
unspecified type. It ensures that client code can't accidentally create 
non-singleton instances of the class.

Regards,
Tobias