[boost] Re: Lock-free shared_ptr on g++/x86, test/review needed

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.