Boost logo

Boost :

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?


> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at