This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch (preview)] libstdc++/24469


On Fri, 1 Sep 2006, Paolo Carlini wrote:

> Hi,
> 
> the below is what I'm currently testing: seems ok from the correctness point
> of view on x86/x86_64/ia64. Likewise, the performance testsuite seems ok,
> really very, very close to the current numbers on an x86 machine I can 100%
> control, more variance on some multiway x86_64 machines, but still ok, I
> think. I'm attaching the outputs and, in any case, I will double check
> everything.
> 
> Anyway, the idea basically is due to Richard (and as such will be properly
> acknowledged ;) : two different _M_used, one not involved in concurrent
> accesses, the numbers merged at deallocation time.
> 
> My "interpretation" of it boils down to *extending* instead the memory pointed
> by the very same _M_used, to avoid changing the class-layout (see
> _M_initialize). Then, any thread can increase his own normal counter stored in
> the first half of _M_used (no atomics needed); every thread can also decrease
> his own _M_used counter, *but* if a thread want to decrease the counter of
> another thread can't do that directly, has to *increase* instead the
> corresponding atomic counter stored in the second half of _M_used (I call this
> second part of _M_used, the reclaimed part). Eventually, or, at the beginning
> of _M_reclaim_block, all the info above is merged and updated.
> 
> Note that _M_reserve_block - where we are only increasing the counters in the
> first half of _M_used, exactly as we are currently doing - is completely
> unchanged, this is important for the binary compatibility because those
> operations are inlined (_M_adjust_freelist).
> 
> I think everything is fine... Otherwise, please stop me before it's too late!
> :)

I'm only concerned about using _Atomic_word in place of size_t and their
possible different size and alignment requirement.  Though it looks safe
from looking at the atomic_word.h files we have:

libstdc++-v3/config/cpu$ grep _Atomic_word */atomic_word.h
alpha/atomic_word.h:typedef int _Atomic_word;
cris/atomic_word.h:typedef int _Atomic_word __attribute__ ((__aligned__ 
(4)));
generic/atomic_word.h:typedef int _Atomic_word;
ia64/atomic_word.h:typedef int _Atomic_word;
powerpc/atomic_word.h:typedef int _Atomic_word;
sparc/atomic_word.h:  typedef long _Atomic_word;
sparc/atomic_word.h:  typedef int _Atomic_word;

(the cris one looks weird at least - what is sizeof(int) there?)

Richard.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]