lkml.org 
[lkml]   [2007]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures
Date
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@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-09-10 22:03    [W:0.166 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site