Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures | Date | Mon, 10 Sep 2007 15:59:06 -0400 |
| |
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/
| |