Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Joe Seigh
Date : Sun Apr 10 2005 11:22 am

On Sun, 10 Apr 2005 16:23:39 +0300, Peter Dimov <pdimov@gmail.com> wrote:

> Chris Thomasson wrote:
>>> As a practical matter, I'd think you'd want some mechanism to
>>> distinguish between shared global pointers and non-shared local
>>> pointers.
>>
>> Agreed. For instance, I had to separate my atomic pointer into two
>> distinguishable classes to address a highly critical performance
>> issue:
>> shared_smr_ptr<T>
>> local_smr_ptr<T>
>>
>>
>> shared_smr_ptr<T> alone is "way to expensive" to be used for a general
>> purpose smart pointer.
>
> That's what people tell me all the time, that shared_ptr is too expensive
> and they need an "unsynchronized" variant.
>
> But it's not quite the same as Joe's local_ptr, I think; it still atomically
> updates its count. I think I'll reserve the local_ptr name for a pointer
> that uses a "local" count and non-atomic updates (but is convertible from
> and to a shared_ptr) so that people are free to shoot themselves in the
> foot, if they so insist.
>
>
local_ptr atomically updates the reference counts.   It has less overhead
than atomic_ptr since it doesn't have to maintain pointer atomicity, just
reference count atomicity.  The main difference is you don't have to use
an interlocked primative to swap pointer values on an pointer assignment
which atomic_ptr does.  So local_ptr looks like the thread-safe version
of shared_ptr somewhat.

The main difference between local_ptr and atomic_ptr is the swap method
and the function used to safely increment the reference count.
atomic_ptr::swap() is atomically thread-safe, local_ptr::swap() is not.
If I get around to merging the compare and swap and (ll/sc, lwarx/stwcx) versions
of atomic_ptr it will become a little clearer since I'll have to
clean up the abstraction boundaries a little better.

-- 
Joe Seigh

.