Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit f5620df7 authored by Palmer Dabbelt's avatar Palmer Dabbelt Committed by Jonathan Corbet
Browse files

Documentation: atomic_ops.txt is core-api/atomic_ops.rst 



I was reading the memory barries documentation in order to make sure the
RISC-V barries were correct, and I found a broken link to the atomic
operations documentation.

Signed-off-by: default avatarPalmer Dabbelt <palmer@dabbelt.com>
Acked-by: default avatarWill 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 52b3f239

Documentation/memory-barriers.txt

+5 −5
Original line number Diff line number Diff line
@@ -498,11 +498,11 @@ And a couple of implicit varieties: 
     This means that ACQUIRE acts as a minimal "acquire" operation and

     RELEASE acts as a minimal "release" operation.



A subset of the atomic operations described in atomic_ops.txt have ACQUIRE

and RELEASE variants in addition to fully-ordered and relaxed (no barrier

semantics) definitions.  For compound atomics performing both a load and a

store, ACQUIRE semantics apply only to the load and RELEASE semantics apply

only to the store portion of the operation.

A subset of the atomic operations described in core-api/atomic_ops.rst have

ACQUIRE and RELEASE variants in addition to fully-ordered and relaxed (no

barrier semantics) definitions.  For compound atomics performing both a load

and a store, ACQUIRE semantics apply only to the load and RELEASE semantics

apply only to the store portion of the operation.



Memory barriers are only required where there's a possibility of interaction

between two CPUs or between a CPU and a device.  If it can be guaranteed that