This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch (preview)] libstdc++/24469
- From: Richard Guenther <rguenther at suse dot de>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Fri, 1 Sep 2006 13:37:39 +0200 (CEST)
- Subject: Re: [Patch (preview)] libstdc++/24469
- References: <44F78DB9.9080000@suse.de>
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