Re: [PATCH] Restore mempools functionality for MemBlob

 On Wed, 30 Mar 2011 15:46:04 -0600, Alex Rousskov wrote:
> On 03/30/2011 02:59 PM, Kinkie wrote:
>
>>> * If pools are indeed not initialized (and they would not be during
>>> some
>>> static allocations), we should not access StrPoolsAttrs at all!
>>> There
>>> are different initialization stages here, and you have to handle
>>> the all
>>> of them for the code to work reliably.
>
>> Why? StrPoolAttrs is statically initialized in the same translation
>> unit as memAllocString. If memAllocString can be called, it has
>> already been initlaized.
>
> The last bit is incorrect, AFAIK.
>
> StrPoolAttrs being static (I actually missed that part due to the
> terrible syntax used for its declaration!) guarantees that it will be
> either all zeros or initialized when memAllocString() is called. The
> code calling memAllocString() does not know anything about
> StrPoolAttrs
> and StrPoolAttrs is not local to memAllocString(), so there is no
> guarantee that StrPoolAttrs will be initialized before the first
> call.
>
> I could not find the exact reference quickly, but the following FAQ
> describes the same "static initialization order fiasco" problem,
> albeit
> indirectly:
> http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14
>

 The fiasco is a peculiarity of methods. Which need valid *this.

 We are dealing with static constant array. I would be surprised if the
 compiler did not optimize that down to a hard-coded piece of
 pre-initialized memory on the heap.

 Hmm, is the a real dependable guarantee of it being zero?
  or do we actually have to deal with the random values situation?

 If it *is* guaranteed zero we are safe, any size will be <=
 StrPoolAttrs[0].obj_size.
 And also the i < count iterator abort will cut in preventing any
 further array checks quite optimally.

 Problems remain if the array count global is initialized but not the
 array, or if either is set to random values before initialization.

 We could avoid the counter/array disconnect problem by terminating the
 array with an entry of zeros, avoiding the need for an array counter
 entirely.

 Amos

>
>> In any case, I failed to convince you of the viability of this
>> approach. As promised, I'll then implement your suggestion of
>> assigning max(pool_size)+1 to early allocations;
>
> I do not insist on the M+1 hack. If others think that the check is
> not
> worth the extra KBs for early allocations, it can go. I am just
> presenting what I consider is a viable option so that we can make an
> informed decision rather than just removing a useful check as "not
> needed".
>
> Thank you,
>
> Alex.
Received on Wed Mar 30 2011 - 22:46:43 MDT