Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Joe Seigh
Date : Mon Apr 11 2005 08:15 pm

On Tue, 12 Apr 2005 01:45:10 +0300, Peter Dimov <pdimov@gmail.com> wrote:

> Joe Seigh wrote:
>>
>> You could, though you've in effect merged atomic_ptr and local_ptr
>> together. As a practical matter, I'd think you'd want some mechanism
>> to distinguish between shared global pointers and non-shared local
>> pointers.
>
> I'm not sure.
>
> I can see how "thread safety is part of the type" can be useful.
>
> But on the other hand "int" offers "basic" thread safety by default and
> "strong" thread safety if I only touch it with atomic_load_acq and
> atomic_store_rel.
>
> Of course in Java "int" is basic and "volatile int" is strong.
>
> For some reason I think that the "non-Java int" (and raw pointer) semantics
> make more sense for shared_ptr; it seems sufficiently primitive to me. I may
> be wrong, of course.
>
> This is also why I'm not particularly fond of Alexander's atomic<> dedicated
> wrapper type. Providing atomic access via ordinary functions seems more
> natural.
>
>

I meant it wouldn't be clear from the code context what was safe or not.
You'd have to know that a particular instance of shared_ptr is used
is a certain way to know that methods were safe or not.  If sp1 and
sp2 are shared pointers how do you know which of the following to use?
   sp1 = sp2;
   sp1 = sp2.copy();
   sp1.replace(sp2);
   sp1.replace(sp2.copy());


Whereas if you keep them as two separate types you can keep the methods
consistent for each type.  So for example, given atomic_ptr ap and
local_ptr lp which by the rules for local_ptr is always local or "owned".
   ap = lp;
   lp = ap;

or any combination of atomic_ptr and local_ptr is safe, always.  You
don't have to know anything about ap or lp.

atomic<T> is the same idea applied to dumb (raw) pointers or other native
types.

-- 
Joe Seigh

.