From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-05 07:45:36
Alexander Terekhov wrote:
> Peter Dimov wrote:
>> Now that I think of it, compiler value propagation isn't a problem
>> either because of the "memory" clobber on the decrement. So the cast
>> to volatile can be removed.
>> void release() // nothrow
>> if( atomic_exchange_and_add( &use_count_, -1 ) == 1 )
>> if( weak_count_ == 1 ) // no weak ptrs
> (this doesn't convey the notion of (potentially) competing accesses;
> who says that implementation can't read it bit-after-bit-and-sum-it,
> bytes aside for a moment... just for the sake of breaking your logic?)
Hm. You are right in theory, but in practice, I know that this is g++ on
x86, and I know that it doesn't do such things.
(Aside: why invent naked_competing instead of just using nsync as per PL2?)
> ... you also have and manage client-provided "deleter" objects and
> I see no reason why weak_ptr clients may NOT have access to them
> (resulting in similar problem with respect to access and
> destruction as with Whitehead's mutex).
IIUC, you are saying that a thread can obtain access to the deleter using
get_deleter, then hold on to the returned pointer after the shared_ptr is
destroyed while holding only a weak_ptr to the object to keep the deleter
I'm having trouble picturing a situation where disallowing this will be a
Via the pointer you can only _read_ the deleter safely, and only if its
operator() is const (because operator() can be called at any time.) Hence,
you could have performed the reads beforehand, while still holding a
This aside, is this a problem on x86? I don't think it is since the load has
acquire semantics either way.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk