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

[Chris Friesen]

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/