forked from luck/tmp_suning_uos_patched
locking/Documentation: Clarify relationship of barrier() to control dependencies
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.desnoyers@efficios.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bobby.prani@gmail.com Cc: dhowells@redhat.com Cc: dipankar@in.ibm.com Cc: dvhart@linux.intel.com Cc: edumazet@google.com Cc: fweisbec@gmail.com Cc: jiangshanlai@gmail.com Cc: josh@joshtriplett.org Cc: oleg@redhat.com Cc: rostedt@goodmis.org Link: http://lkml.kernel.org/r/1460476375-27803-1-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
parent
5c8a010c24
commit
a5052657c1
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue
Block a user