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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk