Re: What does atomic_read actually do?

["Joseph Seigh" <jseigh_02@xemaps.com>]

On Mon, 20 Dec 2004 13:52:23 +0100, Andrea Arcangeli <andrea@suse.de>  
wrote:
>
> set_pte_atomic also requires atomicity in
> asm-generic/pgtable.h:ptep_establish, but it's not even using volatile
> and it's a 64bit pointer that we're writing to.  We're relaying on the
> compiler to do the right thing for us. I don't think it's a good idea
> for the long run, but Benjamin on ppc64 rejected my suggestion to
> rewrite set_pte_atomic in asm, so I doubt you'll be able to rewrite
> atomic_read with asm either (because at least atomic_read is an int and
> not a long pointer, and at least atomic_read is a volatile unlike
> set_pte).
>
> My point is that even before worrying about the theoretical correctness
> of atomic_read, I would suggest to worry about set_pte_atomic first,
> which is a lot more likely to break if something. The compiler may truly
> execute two separate writes if power of 2 bitshifts are involved, as the
> optimal compilation of the C source.

Actually, I'm programming out in user space.  I was looking at the atomic.h
stuff to see how much would be usable.  But I have to look at reading
and writing pointers atomically also since that is heavily used in  
lock-free
programming, e.g. RCU for preemptive user threads which I have a couple of
implementations for.  I remember a discussion a while back about dependent
load memory ordering (alpha doesn't have it) for RCU but I don't recall any
discussion of the requirement for gcc to do atomic loads and stores.  I  
guess
it's just assumed.

It would be nice to have macros tied to the linux ones, ie. check the  
current
linux versions when porting them.  But I can always use asm if I have to.   
I'll
probably have to modify the conditions of use to say "no warranty is  
implied
and we really do mean it" and add a compiler flag to select between the  
safe asm
version and the "Do you feel lucky?" C macro version.

Joe Seigh