From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2005-04-05 09:08:09
Peter Dimov wrote:
[...]
> 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?)
G++ is (relatively) easy to patch, and naked_competing simply sounds
better. ;-)
[...]
> > ... 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).
>
> Hmmmm.
>
> 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
> alive?
Not necessarily just to keep the deleter alive. But ok, why not?
>
> I'm having trouble picturing a situation where disallowing this will be a
> problem.
I'd rather provide
template<class D, class T>
D * get_deleter(weak_ptr<T> const & p);
in addition to your existing
template<class D, class T>
D * get_deleter(shared_ptr<T> const & p);
>
> 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
> shared_ptr.
Deleter can synchronize mutations (which might be caused by both
shared_ptr and weak_ptr clients) internally with or *without*
locks (using some lock-free stuff).
>
> This aside, is this a problem on x86?
No.
> I don't think it is since the load has
> acquire semantics either way.
Right. But I'd still (apart from evil-but-lawful G++ patches/new
versions theory, not current practice) hide it in asm'd "may not
store zero" decrement.
regards,
alexander.