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:I'm aware of that. I'm not asking a question about x86 architecture. I'm
> 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
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,
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
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
up with a separate compliance certification for C compilers. So when you
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.
the assurance that gcc supports this api correctly? There was the
since the C standard leaves it implementation dependent what constitutes
volatile access, that gcc did something special there. But the gcc
says this for volatile, "There is no guarantee that these reads and writes
especially for objects larger than int."
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/