[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F5A2B8BD-CD28-44EE-9DB5-5E776279100F@mac.com>
Date: Mon, 10 Sep 2007 15:59:06 -0400
From: Kyle Moffett <mrmacman_g4@....com>
To: Denys Vlasenko <vda.linux@...glemail.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Nick Piggin <piggin@...erone.com.au>,
Satyam Sharma <satyam@...radead.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
Paul Mackerras <paulus@...ba.org>,
Christoph Lameter <clameter@....com>,
Chris Snook <csnook@...hat.com>,
Ilpo Jarvinen <ilpo.jarvinen@...sinki.fi>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Stefan Richter <stefanr@...6.in-berlin.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>, ak@...e.de,
heiko.carstens@...ibm.com, David Miller <davem@...emloft.net>,
schwidefsky@...ibm.com, wensong@...ux-vs.org, horms@...ge.net.au,
wjiang@...ilience.com, cfriesen@...tel.com, zlynx@....org,
rpjday@...dspring.com, jesper.juhl@...il.com,
segher@...nel.crashing.org
Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Sep 10, 2007, at 12:46:33, Denys Vlasenko wrote:
> My point is that people are confused as to what atomic_read()
> exactly means, and this is bad. Same for cpu_relax(). First one
> says "read", and second one doesn't say "barrier".
Q&A:
Q: When is it OK to use atomic_read()?
A: You are asking the question, so never.
Q: But I need to check the value of the atomic at this point in time...
A: Your code is buggy if it needs to do that on an atomic_t for
anything other than debugging or optimization. Use either
atomic_*_return() or a lock and some normal integers.
Q: "So why can't the atomic_read DTRT magically?"
A: Because "the right thing" depends on the situation and is usually
best done with something other than atomic_t.
If somebody can post some non-buggy code which is correctly using
atomic_read() *and* depends on the compiler generating extra
nonsensical loads due to "volatile" then the issue *might* be
reconsidered. This also includes samples of code which uses
atomic_read() and needs memory barriers (so that we can fix the buggy
code, not so we can change atomic_read()). So far the only code
samples anybody has posted are buggy regardless of whether or not the
value and/or accessors are flagged "volatile" or not. And hey, maybe
the volatile ops *should* be implemented in inline ASM for future-
proof-ness, but that's a separate issue.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists