Re: What does atomic_read actually do?

From: Joseph Seigh
Date: Sun Dec 19 2004 - 18:47:19 EST

On Sun, 19 Dec 2004 17:21:06 -0500, Robert Love <rml@xxxxxxxxxx> wrote:

On Sat, 2004-12-18 at 15:43 -0500, Joseph Seigh wrote:

> it does so on *x86

Is this documented for gcc anywhere? Just because it does so doesn't
mean it's guaranteed.

Listen to what Arjan is saying: It is not a compiler feature. x86
already guarantees that an aligned word-size read is atomic in the
nothing-can-interleave sense.

I'm aware of that. I'm not asking a question about x86 architecture. I'm
asking what guarantees that the compiler will load the int using one MOV
instruction since there's nothing in the C standard that requires that, even
for volatile. I think it's unlikely the compiler would use multiple loads
a byte at a time but it really requires a compiler person to authoritatively
make that statement.

It's a big problem getting support for threaded programming in C since the
C standard doesn't acknowlege threads. For Posix threads, Posix had to come
up with a separate compliance certification for C compilers. So when you use
posix pthreads, you have to use a posix compliant compiler to ensure your
program will work correctly.

It's the same issue here. The atomic functions are another thread api. 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."

Joe Seigh

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