Cc: Paul Mackerras <paulus@...>, Satyam Sharma <satyam@...>, Stefan Richter <stefanr@...>, Chris Snook <csnook@...>, Linux Kernel Mailing List <linux-kernel@...>, <linux-arch@...>, Linus Torvalds <torvalds@...>, <netdev@...>, Andrew Morton <akpm@...>, <ak@...>, <heiko.carstens@...>, <davem@...>, <schwidefsky@...>, <wensong@...>, <horms@...>, <wjiang@...>, <cfriesen@...>, <zlynx@...>, <rpjday@...>, <jesper.juhl@...>, <segher@...>, Herbert Xu <herbert@...>, Paul E. McKenney <paulmck@...>
On Friday 24 August 2007 18:15, Christoph Lameter wrote:
But here you do have some notion of time:
while (atomic_read(&x))
continue;
"continue when other CPU(s) decrement it down to zero".
If "read" includes an insn which accesses RAM, you will
see "new" value sometime after other CPU decrements it.
"Sometime after" is on the order of nanoseconds here.
It is a valid concept of time, right?
The whole confusion is about whether atomic_read implies
"read from RAM" or not. I am in a camp which thinks it does.
You are in an opposite one.
We just need a less ambiguous name.
What about this:
/**
* atomic_read - read atomic variable
* @v: pointer of type atomic_t
*
* Atomically reads the value of @v.
* No compiler barrier implied.
*/
#define atomic_read(v) ((v)->counter)
+/**
+ * atomic_read_uncached - read atomic variable from memory
+ * @v: pointer of type atomic_t
+ *
+ * Atomically reads the value of @v. This is guaranteed to emit an insn
+ * which accesses memory, atomically. No ordering guarantees!
+ */
+#define atomic_read_uncached(v) asm_or_volatile_ptr_magic(v)
I was thinking of s/atomic_read/atomic_get/ too, but it implies "taking"
atomic a-la get_cpu()...
--
vda
-
