Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Peter Dimov
Date : Mon Apr 11 2005 03:26 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 ) )
>>>  {
>>>    // 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().

No, no.

This is about local_shared_ptr, not about copy/replace. The 
local_shared_ptrs in an ownership group (which needs to be local to a 
specific thread) use a local unsynchronized reference count to keep track of 
their single shared_ptr-like reference into the shared_ptr group. ChrisX got 
it right, but I still think that there's no need to acquire in the 
increment, it's an ordinary 'add_ref_strong'.

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

The above local_shared_ptr does not need to steal ownership away from the 
source shared_ptr, nor does it need an unique source. And you can also get a 
real shared_ptr back, again without the 'unique' requirement on the local 
source.

It's like intrusive_ptr_st< shared_ptr_mt<X> >.

.