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


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 ) )
> >  {
> >    // 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.

.

0