From: Pranith Kumar <bobby.prani@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
David Howells <dhowells@redhat.com>,
Masanari Iida <standby24x7@gmail.com>,
linux-kernel@vger.kernel.org (open list)
Subject: [PATCH] doc: memory-barriers.txt: Minor correction in Control dependencies
Date: Mon, 11 Aug 2014 18:51:39 -0400 [thread overview]
Message-ID: <1407797503-24727-1-git-send-email-bobby.prani@gmail.com> (raw)
Minor corrections in memory-barriers.txt document.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
Documentation/memory-barriers.txt | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index abec3f9..41a6c9c 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -627,7 +627,7 @@ proving the value of 'a', and the pair of barrier() invocations are
required to prevent the compiler from pulling the two identical stores
to 'b' out from the legs of the "if" statement.
-It is important to note that control dependencies absolutely require a
+It is important to note that control dependencies absolutely require
a conditional. For example, the following "optimized" version of
the above example breaks ordering, which is why the barrier() invocations
are absolutely required if you have identical stores in both legs of
@@ -652,7 +652,7 @@ for example, as follows:
do_something();
} else {
barrier();
- ACCESS_ONCE(b) = q / 3;
+ ACCESS_ONCE(b) = q / 2;
do_something_else();
}
@@ -710,7 +710,7 @@ x and y both being zero:
The above two-CPU example will never trigger the assert(). However,
if control dependencies guaranteed transitivity (which they do not),
-then adding the following two CPUs would guarantee a related assertion:
+then adding the following CPU would guarantee a related assertion:
CPU 2
=====================
@@ -719,8 +719,8 @@ then adding the following two CPUs would guarantee a related assertion:
assert(!(r1 == 2 && r2 == 1 && x == 2)); /* FAILS!!! */
But because control dependencies do -not- provide transitivity, the
-above assertion can fail after the combined four-CPU example completes.
-If you need the four-CPU example to provide ordering, you will need
+above assertion can fail after the combined three-CPU example completes.
+If you need the three-CPU example to provide ordering, you will need
smp_mb() between the loads and stores in the CPU 0 and CPU 1 code fragments,
that is, just before or just after the "if" statements.
--
1.9.1
next reply other threads:[~2014-08-11 22:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 22:51 Pranith Kumar [this message]
2014-08-11 22:51 ` [PATCH] doc: memory-barriers.txt: Add barrier() to provide ordering Pranith Kumar
2014-08-13 22:50 ` Paul E. McKenney
2014-08-11 22:51 ` [PATCH] sched: Remove ACCESS_ONCE() for jiffies Pranith Kumar
2014-08-12 5:55 ` Peter Zijlstra
2014-08-12 14:42 ` Pranith Kumar
2014-08-12 22:11 ` David Rientjes
2014-08-11 22:51 ` [PATCH] compiler.h: Move __memory_barrier() use to compiler-intel.h Pranith Kumar
2014-08-13 22:49 ` [PATCH] doc: memory-barriers.txt: Minor correction in Control dependencies Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1407797503-24727-1-git-send-email-bobby.prani@gmail.com \
--to=bobby.prani@gmail.com \
--cc=dhowells@redhat.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=standby24x7@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®