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

From: Chris Friesen
Date: Tue Aug 07 2007 - 18:46:37 EST


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

Could you elaborate? From the point of view of the compiler, it "knows" that the variable doesn't change inside the loop.

In the "volatile considered evil" discussion in May of this year, Alan Cox explicitly mentioned the implementation of atomic primitives as a case where "volatile" might be required.

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.

In the example I gave, as far as the compiler can detect there are no dependencies. The code that changes the value is in a different compilation unit.

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.

I certainly agree with this statement.

This leads logically to the question of whether there are cases where the compiler cannot detect that serialization is needed when implementing atomic_t accessor functions. Previously in this thread you've said that there are not, while I've attempted to show that it is possible.

Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/