Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1376973 > unrolled thread

[PATCH memory-barriers.txt 1/7] documentation: Clarify relationship of barrier() to control dependencies

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH memory-barriers.txt 1/7] documentation: Clarify relationship of barrier() to control dependencies "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-12 18:00 +0200
    [tip:locking/core] locking/Documentation: Clarify relationship of  barrier() to control dependencies "tip-bot for Paul E. McKenney" <tipbot@zytor.com> - 2016-04-13 09:30 +0200
    Re: [PATCH memory-barriers.txt 1/7] documentation: Clarify  relationship of barrier() to control dependencies Steven Rostedt <rostedt@goodmis.org> - 2016-04-14 06:00 +0200
      Re: [PATCH memory-barriers.txt 1/7] documentation: Clarify  relationship of barrier() to control dependencies "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-14 17:30 +0200

#1376973 — [PATCH memory-barriers.txt 1/7] 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>
---
 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

[toc] | [next] | [standalone]

#1377597 — [tip:locking/core] locking/Documentation: Clarify relationship of barrier() to control dependencies

Commit-ID:  a5052657c164107032d521f0d9e92703d78845f2
Gitweb:     http://git.kernel.org/tip/a5052657c164107032d521f0d9e92703d78845f2
Author:     Paul E. McKenney <paulmck@linux.vnet.ibm.com>
AuthorDate: Tue, 12 Apr 2016 08:52:49 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 13 Apr 2016 08:52:21 +0200

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>
---
 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 3729cbe..ec12890 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

[toc] | [prev] | [next] | [standalone]

#1378464 — Re: [PATCH memory-barriers.txt 1/7] documentation: Clarify relationship of barrier() to control dependencies

On Tue, 12 Apr 2016 08:52:49 -0700
"Paul E. McKenney" <paulmck@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.desnoyers@efficios.com>
> Signed-off-by: Paul E. McKenney <paulmck@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

[toc] | [prev] | [next] | [standalone]

#1379027 — Re: [PATCH memory-barriers.txt 1/7] documentation: Clarify relationship of barrier() to control dependencies

On Wed, Apr 13, 2016 at 11:56:14PM -0400, Steven Rostedt wrote:
> On Tue, 12 Apr 2016 08:52:49 -0700
> "Paul E. McKenney" <paulmck@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.desnoyers@efficios.com>
> > Signed-off-by: Paul E. McKenney <paulmck@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"?

From https://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law:

	"Law" originally referred to legislative statute, but in the
	idiom may refer to any kind of rule.

So I believe that the current wording respects the spirit of that idiom.  ;-)

							Thanx, Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web