Re: [v3] __pool_alloc rework

[Paolo Carlini <pcarlini at suse dot de>]

Benjamin Kosnik wrote:

> > 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.
>  
Ah, ok... At same point I thought we were aiming to 3.4.1 for this work...

> > > 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.
>  
Again, ok, indeed, if the abstraction layer is perfect wrt to this.

> > 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.
>  
I will, later today, or at most tomorrow. I wanted to do that, but then 
we decided to
rework the allocators rather heavily in the light of this issue wrt 
type-less pools.
That seemed to me just a minor tweak on top of that.

However, if for 3.4.1 we want to have *only* the alignment bits 
additionally to
what we already have, fine with me, of course.

> > !   __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?
>  
Well, if __bytes == 1 then __i is definitely zero.

Paolo.