John Maddock wrote:
I'm looking at the code for singleton_pool, and I can't *quite* convince myself that it's completely thread safe and guaranteed to do what it says, the code in question is in boost/pool/detail/singleton.hpp which is a deceptively clever/simple singleton implementation. I haven't been able to break it in practice, but would a sufficiently clever compiler be able to optimize away the call create_object.do_nothing(); and therefore not instantiate the object prior to main()?
No cause it's static and hence compiler wont remove it. I think it is suffisent, but I would worry of *other* static object in different TU calling singleton instance as the order of static initializer is random. Thread safe singleton are huge beasts to get right, see http://stackoverflow.com/questions/6915/thread-safe-lazy-contruction-of-a-si...
Sigh... yes that's why we *still* don't have a singleton in Boost.
I think our best bet is having some atomic compare&swap in the singleton construction to be sure it is done properly.
That was what I was hinting at - I had assumed that use of Boost.Thread's call_once was the only way to do this right, and then I saw the code and wasn't so sure.
The thing I'm concerned about is this:
* The code currently relies on a call to a function in a static object to force that object to be instantiated and initialize the singleton, but: * Once compiler optimizations are turned on, that function call will be optimized away to a no-op. * There's now no code that's using the global object. * A clever linker says "hey we don't need this anymore" and removes it from the program image, so: * The singleton no longer gets initialized before main starts (only when it's first called).
Of course this optimization changes program behavior so it ought to be forbidden... but you know I'm paranoid ;-)
Cheers, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost