Emulation/switch-linux
1
0
Fork 0
mirror of https://github.com/fail0verflow/switch-linux.git synced 2025-05-04 02:34:21 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

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

Browse source 
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>
This commit is contained in:
Mark Rutland 2016-11-16 11:13:59 +00:00 • committed by Jonathan Corbet
parent 22917b992d
commit 47f4212210
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
Documentation/atomic_ops.txt
View file

@ -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:
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.