id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
2359	Static initialization problems with fast_pool_allocator	Chris Newbold	Chris Newbold	"
== Detailed analysis from Joaquín M López Muñoz: ==

Hello, I did look hard into pool/detail/singleton.hpp in the past because it deals with a problem that I also had to face in the implementation of Boost.Flyweight. These are my conclusions wrt to pool/detail/singleton.hpp and with respect to the particular problem you're now studying:



* pool/detail/singleton.hpp claims that singleton_default<T>::instance() is automatically called before main() if no user code does it explicitly. Strictly speaking, the implementation does not guarantee this, but only that singleton_default<T>::instance() will be called during the so-called dynamic initialization phase of the program startup sequence. For all practical purposes, however, this is equivalent to the orignal claim, so the problem does not lie here.



* Where the problem lies can be found by looking at the usage of singleton_pool by fast_pool_allocator: notice that singleton_pool is used *only* when fast_pool_allocator::allocate or ::deallocate are invoked. So, it is perfectly possible to construct a fast_pool_allocator without that forcing the compiler to construct the underying singleton_pool *yet*. And this is what's happening indeed, the sequence of objects construction we're having is this:



  1. owned_base::pool_ begins construction

  1.1 call of new pool_lii() inside pool::pool

  1.1.1 a fast_pool_allocator is cted inside pool_lii ctor.

  1.2 pool_ii ends construction

  2. pool_ ends construction

  3. the singleton instance associated to singleton_pool<...>is

  cted before main() because fast_pool_allocator uses it later

  (singleton guarantee).



This sequence is consistent with the guarantees provided by singleton_default<T>. The problem lies in the design of

fast_pool_allocator: as it stands, the construction of a fast_pool_allocator does *not* force the prior construction of the internal singleton instance, and this is a mistake.

If my analysis is correct, to fix the problem one need only ensure that his construction order is preserved for instance by explicitly using singleton_pool<...> inside fast_pool_allocator ctors like this:



{{{
    fast_pool_allocator()

    {

      singleton_pool<fast_pool_allocator_tag, sizeof(T),

        UserAllocator, Mutex, NextSize>::is_from(0);

    }



    template <typename U>

    fast_pool_allocator(

        const fast_pool_allocator<U, UserAllocator, Mutex, NextSize> &)

    {

      singleton_pool<fast_pool_allocator_tag, sizeof(T),

        UserAllocator, Mutex, NextSize>::is_from(0);

    }

}}}"	Bugs	closed	Boost 1.37.0	pool	Boost 1.36.0	Problem	fixed		joaquin@…