[PATCH] Remove volatile qualifiers from mt_allocator
Wed Aug 30 13:53:00 GMT 2006
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
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...
More information about the Libstdc++