Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney <hidden>
Date: 2007-08-17 19:49:42
Also in:
linux-arch, lkml
From: Paul E. McKenney <hidden>
Date: 2007-08-17 19:49:42
Also in:
linux-arch, lkml
On Fri, Aug 17, 2007 at 11:54:33AM -0700, Arjan van de Ven wrote:
On Fri, 2007-08-17 at 12:50 -0600, Chris Friesen wrote:quoted
Linus Torvalds wrote:quoted
- in other words, the *only* possible meaning for "volatile" is a purely single-CPU meaning. And if you only have a single CPU involved in the process, the "volatile" is by definition pointless (because even without a volatile, the compiler is required to make the C code appear consistent as far as a single CPU is concerned).I assume you mean "except for IO-related code and 'random' values like jiffies" as you mention later on? I assume other values set in interrupt handlers would count as "random" from a volatility perspective?quoted
So anybody who argues for "volatile" fixing bugs is fundamentally incorrect. It does NO SUCH THING. By arguing that, such people only show that you have no idea what they are talking about.What about reading values modified in interrupt handlers, as in your "random" case? Or is this a bug where the user of atomic_read() is invalidly expecting a read each time it is called?the interrupt handler case is an SMP case since you do not know beforehand what cpu your interrupt handler will run on.
With the exception of per-CPU variables, yes. Thanx, Paul