On Tue, 12 Apr 2016 08:52:49 -0700 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> 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. Which country has the jurisdiction over this barrier() law? What about "the letter of the barrier() rules"? -- Steve > > (*) Control dependencies require at least one run-time conditional > between the prior load and the subsequent store, and this
