lkml.org 
[lkml]   [2007]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: why are some atomic_t's not volatile, while most are?
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-08 00:49    [W:0.057 / U:1.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site