Re: [PATCH] Remove volatile qualifiers from mt_allocator

[Richard Guenther <rguenther at suse dot de>]

On Wed, 30 Aug 2006, Paolo Carlini wrote:

> Richard Guenther wrote:
> 
> >We can "fix" that particular code by doing this adjustment
> >
> >        // Return this block to our list and update counters and
> >        // owner id as needed.
> >        --__bin._M_used[__block->_M_thread_id];
> >
> >only if __block->_M_thread_id == __thread_id as _M_used is only used to
> >optimize reclaiming of thread-local free lists here:
> >  
> >
> [snip]
> 
> and I think you are totally right! I was already considering that change
> myself (nothing in bugzilla, sorry), especially so when we noticed some time
> ago that an *unrelated* change that inadvertently amounted to the same effect
> apparently did work fine and didn't cause any major problem.

Well, in case we would allocate from one thread only and deallocate
from another thread we would need to check if

        unsigned long __remove = __bin._M_free[__thread_id];
        __remove *= __options._M_freelist_headroom;
        if (__remove >= __bin._M_used[__thread_id])
          __remove -= __bin._M_used[__thread_id];
        else
          __remove = 0;

__bin._M_free[__thread_id] * __options._M_freelist_headroom can
ever become bigger than __bin._M_used[__thread_id].  From looking at
the code it seems that __options._M_freelist_headroom is [0, 100],
still if __bin._M_used[__thread_id] would be never shrinking but only
growing we at some point would stop moving freed blocks back to the
global pool.

Of course if we continue to allocate from the local pool always this
doesn't matter.  But surely one can construct some artificial testcase
that would produce very unbalanced local free lists and require more
than usual total memory?

Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs