2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2025-01-18 18:43:59 +08:00

doc: READ_ONCE() now implies smp_barrier_depends()

This commit updates an example in memory-barriers.txt to account for
the fact that READ_ONCE() now implies smp_barrier_depends().

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
[ paulmck: Added MEMORY_BARRIER instructions from DEC Alpha from
  READ_ONCE(), per David Howells's feedback. ]
This commit is contained in:
Paul E. McKenney 2017-10-09 09:15:21 -07:00
parent 4fbd8d194f
commit 4055594644

View File

@ -227,17 +227,20 @@ There are some minimal guarantees that may be expected of a CPU:
(*) On any given CPU, dependent memory accesses will be issued in order, with (*) On any given CPU, dependent memory accesses will be issued in order, with
respect to itself. This means that for: respect to itself. This means that for:
Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q); Q = READ_ONCE(P); D = READ_ONCE(*Q);
the CPU will issue the following memory operations: the CPU will issue the following memory operations:
Q = LOAD P, D = LOAD *Q Q = LOAD P, D = LOAD *Q
and always in that order. On most systems, smp_read_barrier_depends() and always in that order. However, on DEC Alpha, READ_ONCE() also
does nothing, but it is required for DEC Alpha. The READ_ONCE() emits a memory-barrier instruction, so that a DEC Alpha CPU will
is required to prevent compiler mischief. Please note that you instead issue the following memory operations:
should normally use something like rcu_dereference() instead of
open-coding smp_read_barrier_depends(). Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER
Whether on DEC Alpha or not, the READ_ONCE() also prevents compiler
mischief.
(*) Overlapping loads and stores within a particular CPU will appear to be (*) Overlapping loads and stores within a particular CPU will appear to be
ordered within that CPU. This means that for: ordered within that CPU. This means that for: