This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Remove volatile qualifiers from mt_allocator
On Wed, 30 Aug 2006, Paolo Carlini wrote:
> Richard Guenther wrote:
>
> >You cannot only protect the __block->_M_thread_id != __thread_id with
> >a mutex, you would need to protect all _M_used readers/writers, but then...
> >
> >
> Right, at allocation time in particular.
>
> > >Also, I think Benjamin benchmarked *all* the counters atomic, and the
> > >performance penalty was again big. We could try only _M_used atomic and now
> > >(with the new atomicity.h) that would affect only actually multithreaded
> > >code.
> > >Maybe we can go that route... What do you think?
> > >
> > >
> >...this would be the way to go. And yes, it would of course fix the issue
> >(making the _M_used elements atomic). One could think of more
> >trickier ways to avoid the use of atomic ops in the case where
> >__block->_M_thread_id == __thread_id by having two _M_used counters
> >per thread, one atomic and changed from threads != __thread_id, one
> >changed only from __thread_id which also merges both counters at
> >reclaim time. But this would change class layout.
> >
> >
> Note that we are going to change class layout anyway (and probably we can live
> with that because that isn't the default allocator, etc...), because currently
> _M_used is an array of size_t and would become an array of int. Actually, on
> 64-bit machines I bet the "total" layout would change less with a *pair* of
> ints as you are suggesting for completely different reasons.
>
> Less radical than two counters, we could access the atomic counter always
> atomically at allocation time; atomically at deallocation time when
> __block->_M_thread_id != __thread_id; normally at deallocation time when
> __block->_M_thread_id == __thread_id. I think this is also fine and a tad
> better...
Indeed. As we allocate from our local pool only this is fine.
Richard.
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs