I've thought about this some more and looked at the code in you singleton as well as that of the threading library that your code depends upon. I'm motivated by the fact that things are more complex that I anticipated and your package is "boost ready" with tests, documentation, and appropriate boost macro dependcies. This has convinced me that I don't want to re-do any of this and just want to depend on what you (collectively) have done. This means biting the bullet and creating a dependency on the thread library. I hope whoever is maintaining the thread library won't let me down. Soooooooooooo, now I've got some real serious questions. I'm going to need a threadsafe singleton with the following features. a) no extra features. b) if used in an environment which doesn't have threads, it should compile down to almost nothing and not require linking with the threading library. c) good documentation - mostly done as far as I can tell. I would like to see the singleton library have a tutorial section showing examples in a more "chatty" style. I'm aware of the necessity of "formal" documentation - but it's only really useful after one grasps the functionality and necessity of the package in more intuitive terms. Now assuming that the above is OK - (I can live without c) then I have the real problem. Suppose I want to use this to make the serialization library threadsafe. The singleton package is not currently in boost. In fact, its not even on the review schedule. as I see it I have a couple of options: a) don't do anything, just wait until boost has a threadsafe singleton. I see no progress being made here. Currently there is no singleton implemenation in the review queue. b) hack away with some ad hoc version. - built on lightweight_mutex. Problem here is that there are no tests, no documentation, and no promise to keep it maintained and no promise to not change the interface in the future. (I like the size/speed and header only aspect) c) Incorporate your threadsafe singleton as part of the serialization library. See the section of serializaiton library documentation misc. Which has a number of "standalone" utilities which were need to make the serialization library work. This could be made to work. Problem is that I'm going to have a huge hassle unless its in namespace boost::serialization::singleton which is pretty crazy. Hopefully if something like this gets approved eventually, but then I have to go back and change the namespace reference in the serialization library. Seems silly to me to have to go through this. It would also be pretty confusing as there is another singleton in the "memory pool" library - though this one emphatically says its not a general purpose solution. It would also mean that all the tests (Which MUST be run) would appear as part of the serialization library. This is also very confusing and in appropriate. d) Just insert the singleton into boost/detail. I don't like this for the same reason I don't like depending upon boost/detail/lightweight/mutex: it creates a dependency on a component which has no tests, no documentation, and no promise to keep the interface in the future. This is a big proble for the components that are already in there. I run test on utf8_codecvt facet as part of the serialization library. As a practical matter, I'll probably just end up doing d) as it just takes too long any other way. oh well. Robert Ramey