Commit 47f42122 authored by Mark Rutland's avatar Mark Rutland Committed by Jonathan Corbet

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: default avatarMark 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: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 22917b99
...@@ -90,10 +90,10 @@ compiler optimizes the section accessing atomic_t variables. ...@@ -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() sense as described for atomic_read() and atomic_set(). The READ_ONCE()
macro should be used to prevent the compiler from using optimizations and WRITE_ONCE() macros should be used to prevent the compiler from using
that might otherwise optimize accesses out of existence on the one hand, optimizations that might otherwise optimize accesses out of existence on
or that might create unsolicited accesses on the other. 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: ...@@ -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 ...@@ -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 ...@@ -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.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment