On Wed, May 19, 2010 at 03:50:46PM -0700, Paul E. McKenney wrote: > On Wed, May 19, 2010 at 12:54:49PM -0700, David Miller wrote: > > From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> > > Date: Wed, 19 May 2010 08:01:32 -0700 > > > > > On Wed, May 19, 2010 at 11:03:27PM +1000, Nick Piggin wrote: > > >> For atomic_read it shouldn't matter unless gcc is *really* bad at it. > > >> Ah, for atomic_read, the required semantic is surely ACCESS_ONCE, so > > >> that's where the volatile is needed? (maybe it would be clearer to > > >> explicitly use ACCESS_ONCE?) > > > > > > Explicit use of ACCESS_ONCE() where needed makes a lot of sense to me, > > > and allows better code to be generated for initialization and cleanup > > > code where no other task has access to the atomic_t. > > > > I agree and I want to see this too, but I think with the tree the size > > that it is we have to work backwards at this point. > > > > Existing behavior by default, and optimized cases get tagged by using > > a new interface (atomic_read_light(), test_bit{,s}_light(), etc.) > > Fair enough! Hmm, I'm missing something. David, back up a second, as far as I can see, with Anton's patches, atomic_read() *is* effectively just ACCESS_ONCE() now. Linus pointed out that header tangle is the reason not to just use the macro. Am I wrong, or is it that ACCESS_ONCE has a more relaxed semantic *in theory* that allows a future more aggressive implementation if the compiler supports it? do { done = ACCESS_ONCE(blah); } while (!done); Is this (in theory) allowed to be turned into a branch into an infinite loop? Wheras the volatile deref would require it be reloaded each time? -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html