Re: [PATCH] Remove volatile qualifiers from mt_allocator

[Richard Guenther <rguenther at suse dot de>]

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