[v3] libstdc++/24469

[Richard Guenther]

On 3/16/06, Richard Guenther <richard.guenther@gmail.com> wrote:
> 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'll have a look at the v7 branch.

Looking at __pool<true>::_M_get_thread_id() it looks like we have fallbacks to
either share thread ids or fallback to thread id 0, which both will
break down in
__pool<true>::_M_reserve_block where we rely on the thread-id 0 pools to be
accessed only while holding the bin mutex.  So we will race against
the lock-free
allocations from the fallback thread id 0 (or shared thread id) pools.
 Rather than
falling back to non-threadsafe behavior in _M_get_thread_id() we should raise
an exception here or otherwise abort the program.

Oh, and I think you can safely remove all volatile qualifiers
througout the mt allocator.
And __pool<true>:_M_adjust_freelist does not need atomic operations, because it
seems to be only called for thread-local data through allocate() (if
it were not again
possible that the thread for __pool<true> has id 0 or a shared id, in which case
everything breaks down anyway).

Maybe some write-up of the locking strathegy and invariants that are supposed to
hold for the mt_allocator would be useful to punch more holes into it.

Richard.