Re: [boost] Need second opions from some threading / objectcreationexperts...

Subject: Re: [boost] Need second opions from some threading / objectcreationexperts...
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-05-15 16:19:55

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-singleton-in-c
>
> 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