Re: What does atomic_read actually do?

From: Andrea Arcangeli
Date: Mon Dec 20 2004 - 07:53:51 EST

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

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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at