Re: [boost] Re: shared_ptr and BOOST_DISABLE_THREADS

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-04-25 20:29:36

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.