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