Boost logo

Boost :

Subject: Re: [boost] Need second opions from some threading / objectcreation experts...
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-05-15 11:28:35

>> 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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at