Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool <hidden>
Date: 2007-09-11 02:29:50
Also in:
linux-arch, lkml
From: Segher Boessenkool <hidden>
Date: 2007-09-11 02:29:50
Also in:
linux-arch, lkml
quoted
"volatile" has nothing to do with reordering. atomic_dec() writes to memory, so it _does_ have "volatile semantics", implicitly, as long as the compiler cannot optimise the atomic variable away completely -- any store counts as a side effect.Stores can be reordered. Only x86 has (mostly) implicit write ordering. So no atomic_dec has no volatile semantics
Read again: I said the C "volatile" construct has nothing to do with CPU memory access reordering.
and may be reordered on a variety of processors. Writes to memory may not follow code order on several processors.
The _compiler_ isn't allowed to reorder things here. Yes, of course you do need stronger barriers for many purposes, volatile isn't all that useful you know. Segher