Messages in this thread | | | Date | Mon, 20 Dec 2004 13:52:23 +0100 | From | Andrea Arcangeli <> | Subject | Re: What does atomic_read actually do? |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |