Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1379027
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH memory-barriers.txt 1/7] documentation: Clarify relationship of barrier() to control dependencies |
| Date | 2016-04-14 17:30 +0200 |
| Message-ID | <rnRnt-3WP-41@gated-at.bofh.it> (permalink) |
| References | <rn8To-1ma-15@gated-at.bofh.it> <rn8To-1ma-13@gated-at.bofh.it> <rnGBI-3JG-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[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
csiph-web