summaryrefslogtreecommitdiffstats
path: root/Documentation/memory-barriers.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/memory-barriers.txt')
-rw-r--r--Documentation/memory-barriers.txt25
1 files changed, 12 insertions, 13 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 1adbb8a371c7..7146da061693 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -63,7 +63,6 @@ CONTENTS
- Compiler barrier.
- CPU memory barriers.
- - MMIO write barrier.
(*) Implicit kernel memory barriers.
@@ -75,7 +74,6 @@ CONTENTS
(*) Inter-CPU acquiring barrier effects.
- Acquires vs memory accesses.
- - Acquires vs I/O accesses.
(*) Where are memory barriers needed?
@@ -492,10 +490,9 @@ And a couple of implicit varieties:
happen before it completes.
The use of ACQUIRE and RELEASE operations generally precludes the need
- for other sorts of memory barrier (but note the exceptions mentioned in
- the subsection "MMIO write barrier"). In addition, a RELEASE+ACQUIRE
- pair is -not- guaranteed to act as a full memory barrier. However, after
- an ACQUIRE on a given variable, all memory accesses preceding any prior
+ for other sorts of memory barrier. In addition, a RELEASE+ACQUIRE pair is
+ -not- guaranteed to act as a full memory barrier. However, after an
+ ACQUIRE on a given variable, all memory accesses preceding any prior
RELEASE on that same variable are guaranteed to be visible. In other
words, within a given variable's critical section, all accesses of all
previous critical sections for that variable are guaranteed to have
@@ -1512,8 +1509,6 @@ levels:
(*) CPU memory barriers.
- (*) MMIO write barrier.
-
COMPILER BARRIER
----------------
@@ -1873,12 +1868,16 @@ There are some more advanced barrier functions:
(*) smp_mb__before_atomic();
(*) smp_mb__after_atomic();
- These are for use with atomic (such as add, subtract, increment and
- decrement) functions that don't return a value, especially when used for
- reference counting. These functions do not imply memory barriers.
+ These are for use with atomic RMW functions that do not imply memory
+ barriers, but where the code needs a memory barrier. Examples for atomic
+ RMW functions that do not imply are memory barrier are e.g. add,
+ subtract, (failed) conditional operations, _relaxed functions,
+ but not atomic_read or atomic_set. A common example where a memory
+ barrier may be required is when atomic ops are used for reference
+ counting.
- These are also used for atomic bitop functions that do not return a
- value (such as set_bit and clear_bit).
+ These are also used for atomic RMW bitop functions that do not imply a
+ memory barrier (such as set_bit and clear_bit).
As an example, consider a piece of code that marks an object as being dead
and then decrements the object's reference count:
OpenPOWER on IntegriCloud