Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Peter Dimov
Date : Tue Apr 12 2005 05:03 am

Joe Seigh wrote:
> 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.

Yes, I understood that.

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

No; both lp = ap and ap = lp are unsafe if I don't know anything about lp 
(if another thread can read or write lp), if I understand their semantics 
correctly.

sp1.replace( sp2 );
sp2 = sp1.copy();

are equally safe (and more explicit) if I have the same information about 
sp2 as I do for lp (i.e. it's not visible to other threads.) I admit that 
sometimes encoding the intent that lp is not shared into its type may help 
or appeal to some programmers.

But regardless...

My point was that (low level) concurrent accesses without proper 
synchronization are always "unsafe", so it's a waste of time to try to make 
them safe. "Unsafe" in the sense that it's very, very hard for a non-expert 
to get a lock-free algorithm right. And the expert is unlikely to need his 
pointers color-coded.

But I may be wrong. :-)

.