From: "terekhov" <terekhov@de.ibm.com>
On the other hand placing a memory barrier in shared_ptr will probably be a good thing from user point of view;
I think so too, but how about portability... also, given rather close to NULL amount of interest (wrt the proposal for having portable interface specifically for ref.counting) I've observed on c.p.t, I am not sure at all... maybe I am missing something subtle and the whole idea of a single "RMB" might be a BS... I do not know, really.
Perhaps C++ compilers already do the right thing on "delete p", i.e. synchronize. They need to do that anyway to protect the allocator.
but I don't want to make shared_ptr depend on pthreads.
Yeah, pthreads is not a boost library, but other than that argument and perhaps some licensing issues wrt LGPL nature of pthreads-win32, I do not see why boosters just ignore pthreads. It is a standard and it is available on almost every platform out there (I mean basic threading stuff).
pthreads is fine, it's just that the current smart_ptr.hpp doesn't need pthreads and I wanted to stay backward compatible. -- Peter Dimov Multi Media Ltd.