The current documentation claims that the compiler ignores barrier(),
which is not the case. Instead, the compiler carefully pays attention
to barrier(), but in a creative way that still manages to destroy
the control dependency. This commit sets the story straight.
Reported-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
---
Documentation/memory-barriers.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 3729cbe60e41..ec1289042396 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -813,9 +813,10 @@ In summary:
the same variable, then those stores must be ordered, either by
preceding both of them with smp_mb() or by using smp_store_release()
to carry out the stores. Please note that it is -not- sufficient
- to use barrier() at beginning of each leg of the "if" statement,
- as optimizing compilers do not necessarily respect barrier()
- in this case.
+ to use barrier() at beginning of each leg of the "if" statement
+ because, as shown by the example above, optimizing compilers can
+ destroy the control dependency while respecting the letter of the
+ barrier() law.
(*) Control dependencies require at least one run-time conditional
between the prior load and the subsequent store, and this
--
2.5.2
