1
0
Fork 0

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: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
hifive-unleashed-5.1
Palmer Dabbelt 2017-06-23 13:31:39 -07:00 committed by Jonathan Corbet
parent 52b3f239bb
commit f5620df7e3
1 changed files with 5 additions and 5 deletions

View File

@ -498,11 +498,11 @@ And a couple of implicit varieties:
This means that ACQUIRE acts as a minimal "acquire" operation and This means that ACQUIRE acts as a minimal "acquire" operation and
RELEASE acts as a minimal "release" operation. RELEASE acts as a minimal "release" operation.
A subset of the atomic operations described in atomic_ops.txt have ACQUIRE A subset of the atomic operations described in core-api/atomic_ops.rst have
and RELEASE variants in addition to fully-ordered and relaxed (no barrier ACQUIRE and RELEASE variants in addition to fully-ordered and relaxed (no
semantics) definitions. For compound atomics performing both a load and a barrier semantics) definitions. For compound atomics performing both a load
store, ACQUIRE semantics apply only to the load and RELEASE semantics apply and a store, ACQUIRE semantics apply only to the load and RELEASE semantics
only to the store portion of the operation. apply only to the store portion of the operation.
Memory barriers are only required where there's a possibility of interaction 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 between two CPUs or between a CPU and a device. If it can be guaranteed that