[PATCH] Remove volatile qualifiers from mt_allocator

[Paolo Carlini]

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...

Paolo.