lkml.org 
[lkml]   [2004]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.164 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site