Re: [v3] __pool_alloc rework

[Benjamin Kosnik <bkoz at redhat dot com>]

>Hi Benjamin. I'm not sure to understand why you are using GLIBCXX_3.4.2
>for this?

... I thought 3.4.1 would be out already. 

Anyway, this is unlikely to go on the branch until the locking issues
have been sorted out. There are no exports of locks on 3_4-branch, and
so the current state won't fly.

>>I'm still working on the locking bits, which is the only part of this
>>patch that I'm unhappy with at the moment.
>>
>Indeed, in the case of __pool _alloc the template parameter was *not* 
>unused...

Ummmm.

Well, the template parameter was only used for _Lock, and __pool_alloc
inherited from the explicitly threaded instance of the base class (with
no other instance used...). Since _Lock uses (or should use) a thread
abstraction layer that adds in no overhead when there are no threads,
this will be ok.

>Ok! Please keep me updated: mt_alloc is still missing some alignments bits,
>as you remember.

Ayeeee!

I've been asking for you to put these in for weeks, dude! I thought this
was already in. Did you post this already? If not, can you post just the
alignment bits? Thanks in advance.

>A last thing. The new _M_get_free_list reads:
>
>!   // Static members of __pool_alloc and base class.
>
>(comment out of date, I think)

Okay.

>
>!   __pool_base::_Obj* volatile*
>!   __pool_base::_M_get_free_list(size_t __bytes)
>!   { 
>!     size_t __i = ((__bytes + (size_t)_S_align - 1) / (size_t)_S_align - 1);
>!     return _S_free_list + __i - 1;
>!   }
>
>Are you sure about the final '- 1'??? If I'm not mistaken, 
>_M_get_free_list replaces
>the previous _S_free_list + _S_freelist_index

Yes. In the above, __i is always >= 1, even for __bytes == 0 or 1.
Seemed odd, to have one of the free lists unused. Maybe I'm missing
something?

-benjamin