https://svn.boost.org/trac10/ticket/2359 <h2 class="section" id="DetailedanalysisfromJoaquínMLópezMuñoz:">Detailed analysis from Joaquín M López Muñoz:</h2> <p> 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: </p> <ul><li>pool/detail/singleton.hpp claims that singleton_default&lt;T&gt;::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&lt;T&gt;::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. </li></ul><ul><li>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: </li></ul><ol><li>owned_base::pool_ begins construction </li></ol><blockquote> <p> 1.1 call of new pool_lii() inside pool::pool </p> </blockquote> <blockquote> <p> 1.1.1 a fast_pool_allocator is cted inside pool_lii ctor. </p> </blockquote> <blockquote> <p> 1.2 pool_ii ends construction </p> </blockquote> <ol start="2"><li>pool_ ends construction </li></ol><ol start="3"><li>the singleton instance associated to singleton_pool&lt;...&gt;is </li></ol><blockquote> <p> cted before main() because fast_pool_allocator uses it later </p> </blockquote> <blockquote> <p> (singleton guarantee). </p> </blockquote> <p> This sequence is consistent with the guarantees provided by singleton_default&lt;T&gt;. The problem lies in the design of </p> <p> 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. </p> <p> 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&lt;...&gt; inside fast_pool_allocator ctors like this: </p> <pre class="wiki"> fast_pool_allocator() { singleton_pool&lt;fast_pool_allocator_tag, sizeof(T), UserAllocator, Mutex, NextSize&gt;::is_from(0); } template &lt;typename U&gt; fast_pool_allocator( const fast_pool_allocator&lt;U, UserAllocator, Mutex, NextSize&gt; &amp;) { singleton_pool&lt;fast_pool_allocator_tag, sizeof(T), UserAllocator, Mutex, NextSize&gt;::is_from(0); } </pre> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/2359 Trac 1.4.3 Chris Newbold Mon, 22 Sep 2008 21:02:18 GMT https://svn.boost.org/trac10/ticket/2359#comment:4 https://svn.boost.org/trac10/ticket/2359#comment:4 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">assigned</span> </li> </ul> Ticket Chris Newbold Mon, 29 Sep 2008 18:45:28 GMT https://svn.boost.org/trac10/ticket/2359#comment:5 https://svn.boost.org/trac10/ticket/2359#comment:5 <ul> <li><strong>status</strong> <span class="trac-field-old">assigned</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> Fixed on trunk by revision 49025. </p> Ticket anonymous Thu, 13 Jan 2011 22:19:09 GMT