Przeglądaj źródła

Documentation: atomic_ops: use {READ,WRITE}_ONCE()

While the {READ,WRITE}_ONCE() macros should be used in preference to
ACCESS_ONCE(), the atomic documentation uses the latter exclusively.

To point people in the right direction, and as a step towards the
eventual removal of ACCESS_ONCE(), update the documentation to use the
{READ,WRITE}_ONCE() macros as appropriate.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Mark Rutland 8 lat temu
rodzic
commit
47f4212210
1 zmienionych plików z 9 dodań i 9 usunięć
  1. 9 9
      Documentation/atomic_ops.txt

+ 9 - 9
Documentation/atomic_ops.txt

@@ -90,10 +90,10 @@ compiler optimizes the section accessing atomic_t variables.
 
 
 Properly aligned pointers, longs, ints, and chars (and unsigned
 Properly aligned pointers, longs, ints, and chars (and unsigned
 equivalents) may be atomically loaded from and stored to in the same
 equivalents) may be atomically loaded from and stored to in the same
-sense as described for atomic_read() and atomic_set().  The ACCESS_ONCE()
-macro should be used to prevent the compiler from using optimizations
-that might otherwise optimize accesses out of existence on the one hand,
-or that might create unsolicited accesses on the other.
+sense as described for atomic_read() and atomic_set().  The READ_ONCE()
+and WRITE_ONCE() macros should be used to prevent the compiler from using
+optimizations that might otherwise optimize accesses out of existence on
+the one hand, or that might create unsolicited accesses on the other.
 
 
 For example consider the following code:
 For example consider the following code:
 
 
@@ -112,7 +112,7 @@ the following:
 If you don't want the compiler to do this (and you probably don't), then
 If you don't want the compiler to do this (and you probably don't), then
 you should use something like the following:
 you should use something like the following:
 
 
-	while (ACCESS_ONCE(a) < 0)
+	while (READ_ONCE(a) < 0)
 		do_something();
 		do_something();
 
 
 Alternatively, you could place a barrier() call in the loop.
 Alternatively, you could place a barrier() call in the loop.
@@ -141,7 +141,7 @@ of registers: reloading from variable a could save a flush to the
 stack and later reload.  To prevent the compiler from attacking your
 stack and later reload.  To prevent the compiler from attacking your
 code in this manner, write the following:
 code in this manner, write the following:
 
 
-	tmp_a = ACCESS_ONCE(a);
+	tmp_a = READ_ONCE(a);
 	do_something_with(tmp_a);
 	do_something_with(tmp_a);
 	do_something_else_with(tmp_a);
 	do_something_else_with(tmp_a);
 
 
@@ -166,14 +166,14 @@ that expected b to never have the value 42 if a was zero.  To prevent
 the compiler from doing this, write something like:
 the compiler from doing this, write something like:
 
 
 	if (a)
 	if (a)
-		ACCESS_ONCE(b) = 9;
+		WRITE_ONCE(b, 9);
 	else
 	else
-		ACCESS_ONCE(b) = 42;
+		WRITE_ONCE(b, 42);
 
 
 Don't even -think- about doing this without proper use of memory barriers,
 Don't even -think- about doing this without proper use of memory barriers,
 locks, or atomic operations if variable a can change at runtime!
 locks, or atomic operations if variable a can change at runtime!
 
 
-*** WARNING: ACCESS_ONCE() DOES NOT IMPLY A BARRIER! ***
+*** WARNING: READ_ONCE() OR WRITE_ONCE() DO NOT IMPLY A BARRIER! ***
 
 
 Now, we move onto the atomic operation interfaces typically implemented with
 Now, we move onto the atomic operation interfaces typically implemented with
 the help of assembly code.
 the help of assembly code.