Chris Friesen wrote:
quoted text
> 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.

quoted text
> 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
-
unsubscribe notice
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/