Tweaking atomics and memory barriers in shared_ptr

[Peter Dimov]

Jonathan Wakely:

> Correctness:  _Sp_counted_base::_M_get_use_count() carries a comment I
> left, asking if it is MT safe. I'm pretty sure the answer's no :-)
> It should really be a synchronised atomic load (load acquire, I think)
> so that updates by other threads are visible. The current code assumes
> reading an _Atomic_word is atomic (should be ok) but it has no memory
> synchronisation at all.  In the absence of an atomic load in GCC I've
> used the same hack as Boost's shared_ptr, casting to volatile. IIUC
> this isn't really enough as it only prevents compiler re-orderings,
> not hardware effects, but it's an improvement over the status quo.
> Better ideas would be welcome.

Whether use_count() should have acquire semantics instead of relaxed is not 
quite clear even to me. I can think of no legitimate example of inter-thread 
communication via use_count(), so I tend toward "relaxed", which is 
basically why Boost uses a volatile read.