Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Alexander Terekhov
Date : Mon Apr 11 2005 01:50 pm


Alexander Terekhov wrote:
> 
> Peter Dimov wrote:
> >
> > Chris Thomasson wrote:
> > > local_ptr<X> = shared_ptr<X>
> > > -------------------------------
> > > atomic_inc_acquire( &shared_ptr<X>::refs );
> > > local_ptr<X>::refs = 1;
> > >
> > >
> > > local_ptr<X> = 0
> > > -------------------------------
> > > --local_ptr<X>::refs
> > > if ( ! local_ptr<X>::refs )
> > > {
> > >  if ( ! atomic_dec_acquire( &shared_ptr<X>::refs ) )

That must be upcoming Apple's OSAtomicDecrementRelAcq32() or
OSAtomicDecrementSlbHsb32() (when X is immutable while managed
by shared_ptr<>). ;-) 

> > >  {
> > >    // whatever
> > >  }
> > > }
> >
> > Yes, exactly, but why acquire in the increment?
> 
> In your vocabulary, he means copy(). Your copy() does need acquire
> semantics to ensure visibility of client object "published" by your
> replace().
> 
> BTW, strong thread-safety aside for a moment, I think that you can
> simply provide a "move to/from" operation for shared_ptr<T, D,
> thread_safety::basic>, shared_ptr<T, D, thread_safety::unsafe>, and
> std::auto_ptr<T> (when your D deleter on the other side is
> empty/default). It can throw something if the source is "!empty()
> || !unique()". Or just make it a precondition. Frankly, it all
> boils down to release() call which you don't provide currently. ;-)

regards,
alexander.

.