Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-16 03:15:55


Pierre-Jules,

thank you for your review.

Pierre-Jules Tremblay wrote:
> On Jan 14, 2008 12:10 PM, John Torjo <john.groups_at_[hidden]> wrote:
>
>> * What is your evaluation of the design?
>>
>
> Not generic enough. It addresses a number of specific problems (e.g. use in
> MT contexts, order-of-initialisation fiasco, etc) but the author's design
> choices are neither customizable nor overridable.

> For instance, the design
> could be made more flexible by allowing thread-safety to be specified as a
> policy (with appropriate default) or by delegating the responsibility to the
> wrapped type.

OK, FWIW policies complicate things. And what's their benefit here?

> If BOOST_HAS_THREADS is defined, it looks as though I have no
> choice but to use mutexed instantiation and/or access. If I'm not
> interested in synchronised access, then the lease interface is useless.

Wrong:

The lease interface is useful to improves performance. The test whether
the Singleton has been initialized (which requires synchronization) can
be performed only once.

>
> The solution to the OOI problem does not scale, and I would go as far as
> saying that it doesn't work in practice. In my experience, it's a constant
> maintenance nightmare to try and keep the various slot assignments in the
> correct order (I have to deal with a large number of singletons; yes that is
> a problem in and of itself - this library will do nothing to discourage
> it).

You must have misunderstood the docs. OOI is not done with slots. The
slots are to prevent unnecessary resurrection during destruction.

> The only scheme I've personally had any success with, so far, involves
> some form of reference counting, i.e. singletons that depend on other
> singletons do so explicitly (by incrementing the other's refcount on
> construction; the singletons are destroyed when their refcount goes to
> zero).

You might have gotten away with it in practice, but introducing this
kind of coupling seems really bad design to me.

>
> Another reason why the proposed OOI solution fails in practice is that other
> singletons are not a singleton's only dependency: client code ( e.g. objects
> that reference the singleton) are dependencies as well and may affect the
> order of destruction.

What is the "proposed OOI solution" you are talking about?

> You just can't assume the singleton manager will be
> the last thing to go - there may be other globals.

It's the "we should remove pointers from C++ because one can dereference
NULL" kind-of argumentation.

> BTW I find the very idea
> of being able to "force" singleton destruction quite scary, but I haven't
> looked at the implementation details.

It's necessary, as long as C++ runs on top of ABIs that don't support
code to be run automatically when a dynamic library is unloaded and I
can assure you that running code in an unloaded, dynamic library is a
lot scarier :-).

> The following sentence is also cause
> for concern: " Attempts to access an already destroyed Singleton instance
> cause the instance to be re-created." Is that true only for DLL usage?

It's true in general.

> My biggest problem with this design is that it is unsuitable for library
> writers: types derived from typical singleton class designs, including
> boost::singleton and friends under review, invariably give rise to
> untestable code. To make a singleton's client code testable involves
> exposing some kind of overridable factory so that the singletonized type can
> be replaced with a test mockup. So far I have found this to be a hard
> problem to solve in general.

Interesting point.

>
> Finally, this may constitute a minority opinion but I like to consider
> global access and single instance as orthogonal concepts. One may want to
> ensure a resource is only instantiated once without necessarily providing
> global access to that resource.

So Singletons should be dynamic arrays in your opinion?

Regards,
Tobias


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk