Re: What does atomic_read actually do?

[Andrea Arcangeli <andrea@suse.de>]

On Sun, Dec 19, 2004 at 06:50:54PM -0500, Joseph Seigh wrote:
> What's the assurance that gcc supports this api correctly?   There was
> the  possibility since the C standard leaves it implementation
> dependent what constitutes volatile access, that gcc did something
> special there.  But the gcc  documentation says this for volatile,
> "There is no guarantee that these reads and writes  are atomic,
> especially for objects larger than int."

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.