Messages in this thread | | | From | Segher Boessenkool <> | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures | Date | Sat, 18 Aug 2007 00:09:45 +0200 |
| |
> Of course, since *normal* accesses aren't necessarily limited wrt > re-ordering, the question then becomes one of "with regard to *what* > does > it limit re-ordering?". > > A C compiler that re-orders two different volatile accesses that have a > sequence point in between them is pretty clearly a buggy compiler. So > at a > minimum, it limits re-ordering wrt other volatiles (assuming sequence > points exists). It also means that the compiler cannot move it > speculatively across conditionals, but other than that it's starting to > get fuzzy.
This is actually really well-defined in C, not fuzzy at all. "Volatile accesses" are a side effect, and no side effects can be reordered with respect to sequence points. The side effects that matter in the kernel environment are: 1) accessing a volatile object; 2) modifying an object; 3) volatile asm(); 4) calling a function that does any of these.
We certainly should avoid volatile whenever possible, but "because it's fuzzy wrt reordering" is not a reason -- all alternatives have exactly the same issues.
Segher
- 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/
| |