My vote: Accept the current implementation. I initially thought boost should reject this singleton implementation because it bundles too many concepts into one package. Others have pointed out some clear factorization points. They looked something like: template <class T> class singleton; template <class T> class mutexed_ptr; template <class T> class mutexed_singleton : public singleton<mutexed_ptr<T> >; But a bird in hand is worth two in the bush... While good ideas have been put forth, I don't see their implementation coming soon; and most of these changes should have little effect on the API. Ramblings: Despite the naysayers, boost needs a singleton framework (or at least some concise documentation on how to implement them portably). Ignoring a common idiom won't make it go away. A few purposes for singletons: 1) only create a single object As Anthony points out, this is generally bad and shortsighted. 2) establish a central point of communication This can be a good thing. 3) work around foreign APIs Singletons can save the day when working with callbacks in foreign APIs. Until everyone starts using functor objects or the like, singletons may be the only way to pass "extra parameters" through another library's callback API. 4) simplify public APIs Mirroring the previous point, "dependency injection" can horribly clutter an API. Its fine for a couple things; but carried too far, it can introduce tigher coupling between and an application and a library since the application now has an active role in passing the library state around. This is especially important when adding a new library to "legacy code" where social factors may prevent dependency injection while singletons allow more isolated changes. Of these use cases, only 1 and 2 require special static initialization (3 and 4 may use an explicit init() call). Similarly, none of them require locking semantics, though locking should be easy to specify/enable. - Daniel