Re: What does atomic_read actually do?

From: Joseph Seigh
Date: Sat Dec 18 2004 - 13:10:31 EST

On Sat, 18 Dec 2004 18:11:02 +0100, Paolo Ornati <ornati@xxxxxxxxxxxxx> wrote:

On Sat, 18 Dec 2004 11:23:37 -0500
"Joseph Seigh" <jseigh_02@xxxxxxxxxx> wrote:

It doesn't do anything that would actually guarantee that the fetch
from memory would be atomic as far as I can see, at least in the x86
version. The C standard has nothing to say about atomicity w.r.t.
multithreading or multiprocessing. Is this a gcc compiler thing? If
so, does gcc guarantee that it will fetch aligned ints with a single
instruction on all platforms or just x86? And what's with volatile
since if the C standard implies nothing about multithreading then it
follows that volatile has no meaning with respect to multithreading
either? Also a gcc thing? Are volatile semantics well defined enough
that you can use it to make the compiler synchronize memory state as
far as it is concerned?

sig_atomic_t is only meaningful with respect to unix signals and is meaningless with
respect to threads. And sig_atomic_t isn't atomic_t anyway. And it has to useful
size, it could be in int on some platforms but only a byte on others. Signals and
threading are difficult enough as separate subjects. Combining them is insanely
difficult but that's another topic.

"The C standard leaves it implementation defined as to what constitutes a volatile access."
Plus, I'm not sure sequence points are defined in C, and IIRC, C++ can combine and/or
reorder volatile accesses between sequence points.

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