This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tweaking atomics and memory barriers in shared_ptr


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]