From: "Howard Hinnant"
On Apr 25, 2004, at 6:52 AM, Peter Dimov wrote:
In the std::locale implementation I am careful to wrap each use of the locale implementation with a mutex lock. I believe I would have to do this whether or not shared_ptr protected its count. And yet std::locale is just a library, not an application.
I am not sure whether you can skip the count synchronization here. Even though you do not expose a shared_ptr directly, the user can still copy a std::locale at will. When two threads copy the same std::locale at the same time, a non-synchronized count leads to undefined behavior.
I don't think I was clear. The access is synchronized. The synchronization happens at the locale level, making the synchronization at the shared_ptr level redundant. I need to synchronize more than just the counts in the shared_ptr, namely access to the stuff that the shared_ptr is pointing to.
It is still not clear why you think that the count does not need separate synchronization. The count protection and the pointee protection are orthogonal. Count accesses happen on copy: handle a; // thread 1 handle b(a); // thread 2 handle c(a); Whereas implementation accesses happen on mutable operations: // thread 1 a.f(); // non-const // thread 2 a.g(); // const or non-const You can reuse the implementation mutex to synchronize copies as well, but that's inefficient; you'd be needlessly serializing copies and implementation access, as in: // thread 1 handle b(a); // thread 2 a.g(); // const In fact, it isn't even clear to me why you need to synchronize access to the implementation at all, as std::locale is immutable; it has no non-const member functions. Perhaps some illustrative code can help me understand your point better.