Hey Robert, I know I promised I'd look into it a long time ago, and I finally got around to it. It appears you have addressed the thread-safety issue by ensuring that all the mutable singleton objects get created before main. Is this correct? If so, then the problem is shifted to the implementation-specifics. I see two things that need to be determined for a given compiler/OS: 1) If you dynamically load a dll/shared object (eg, dlopen/LoadLibrary) does your loader guarantee that the global C++ constructors will be called? I recall some Unices that I've had the misfortune of coming across where this is not the case. 2) Does the singleton<T> + static T reference hack work as expected on the compiler? For users, perhaps it would be most helpful to have tests that test the above. I think there are tests that test the second case indirectly. If memory serves, BBv2 is a hurdle to getting the first in a test-case. Perhaps one of the BBv2 gurus can help you there ;-) Other than that, it looks good to me. Good job rewriting the dangerous parts rather than patching in the thread-safety. This is based on my reading and not actually testing the thread-safety so your mileage may vary ;-) -- Sohail Somani http://uint32t.blogspot.com