Chris Friesen wrote:
Chris Snook wrote:
That's why we define atomic_read like so:
#define atomic_read(v) ((v)->counter)
This avoids the aliasing problem, because the compiler must
de-reference the pointer every time, which requires a memory fetch.
Can you guarantee that the pointer dereference cannot be optimised away
on any architecture? Without other restrictions, a suficiently
intelligent optimiser could notice that the address of v doesn't change
in the loop and the destination is never written within the loop, so the
read could be hoisted out of the loop.
That would be a compiler bug.
Even now, powerpc (as an example) defines atomic_t as:
typedef struct { volatile int counter; } atomic_t
That volatile is there precisely to force the compiler to dereference it
every single time.
On most superscalar architectures, including powerpc, multiple instructions can
be in flight simultaneously, potentially even reading and writing the same data.
When the compiler detects data dependencies within a thread of execution, it
will do the right thing. Putting the volatile keyword in here instructs the
compiler to serialize accesses to this data even if it does not detect dependencies.
It's worth noting that all of the SMP architectures which lack the volatile
keyword in their atomic_t definition inherit memory access semantics from ISAs
that predate the advent of heavily-pipelined superscalar design. i386 and
x86_64 get theirs from at least as far back as the 8086. I believe s390(x)
inherits this from the s/370 ISA. These ISAs assume strictly serialized memory
access, and anything binary-compatible with them must enforce this in hardware,
even at the expense of performance. Modern ISAs that lack legacy baggage do
away with this guarantee, putting the burden on the compiler to enforce
serialization. When the compiler can't detect that it's needed, we use volatile
to inform it explicitly.
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
