Thread (305 messages) flat view 305 messages, 27 authors, 2007-09-11

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

From: Chris Snook <hidden>
Date: 2007-08-20 13:39:55
Also in: linux-arch, lkml

Herbert Xu wrote:
On Mon, Aug 20, 2007 at 09:15:11AM -0400, Chris Snook wrote:
quoted
Linus Torvalds wrote:
quoted
So the only reason to add back "volatile" to the atomic_read() sequence is 
not to fix bugs, but to _hide_ the bugs better. They're still there, they 
are just a lot harder to trigger, and tend to be a lot subtler.
What about barrier removal?  With consistent semantics we could optimize a 
fair amount of code.  Whether or not that constitutes "premature" 
optimization is open to debate, but there's no question we could reduce our 
register wiping in some places.
If you've been reading all of Linus's emails you should be
thinking about adding memory barriers, and not removing
compiler barriers.

He's just told you that code of the kind

	while (!atomic_read(cond))
		;

	do_something()

probably needs a memory barrier (not just compiler) so that
do_something() doesn't see stale cache content that occured
before cond flipped.
Such code generally doesn't care precisely when it gets the update, just that 
the update is atomic, and it doesn't loop forever.  Regardless, I'm convinced we 
just need to do it all in assembly.

	-- Chris
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help