Re: why are some atomic_t's not volatile, while most are?

Chris Snook
2007-08-07T22:11:36Z

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