[v3] libstdc++/24469
Richard Guenther
richard.guenther@gmail.com
Thu Mar 16 09:57:00 GMT 2006
On 3/16/06, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> Here is a patch for this bug, for which we still do not have a
> testcase. This patch seems pretty simple, given the previous patches:
> that was the idea.
>
> As expected, performance on x86/linux takes a hit with this approach. I
> haven't yet measured powerpc64 or others yet.
>
> I'd like to check this in to libstdcxx_so_7-branch, but will wait a bit
> for comments.
I see the v7 sources have diverged somewhat from the v6 ones, but
the patch doesn't look correct. Either __thread_bin is per thread, in
which case you don't need any special locking against other threads,
or you are not closing the race window, as f.i.
- --__thread_bin->_M_free;
- ++__thread_bin->_M_used;
+ __exchange_and_add(&__thread_bin->_M_free, -1);
+ __atomic_add(&__thread_bin->_M_used, 1);
will have a window of inconsistent _M_free and _M_used, likewise
__thread_bin._M_first = __tmp->_M_next;
- __thread_bin._M_free -= __removed;
+ __exchange_and_add(&__thread_bin._M_free, -__removed);
does not atomically set _M_first and decrement _M_free (I see in v6 sources
_M_first is a volatile ** -- all uses of volatile are very suspicious).
I'll have a look at the v7 branch.
Richard.
More information about the Gcc-patches
mailing list