From: Akira Yokosawa <akiyks@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Akira Yokosawa <akiyks@gmail.com>
Subject: [PATCH] documentation: Fix two-CPU control-dependency example
Date: Mon, 17 Jul 2017 17:24:42 +0900 [thread overview]
Message-ID: <0d60072f-3848-a2b7-ce18-e1ed317b5c09@gmail.com> (raw)
>From b798b9b631e237d285aa8699da00bfb8ced33bea Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Mon, 17 Jul 2017 16:25:33 +0900
Subject: [PATCH] documentation: Fix two-CPU control-dependency example
In commit 5646f7acc95f ("memory-barriers: Fix control-ordering
no-transitivity example"), the operator in "if" statement of
the two-CPU example was modified from ">=" to ">".
Now the example misses the point because there is no party
who will modify "x" nor "y". So each CPU performs only the
READ_ONCE().
The point of this example is to use control dependency for ordering,
and the WRITE_ONCE() should always be executed.
So it was correct prior to the above mentioned commit. Partial
revert of the commit (with context adjustments regarding other
changes thereafter) restores the point.
Note that the three-CPU example demonstrating the lack of
transitivity stands regardless of this partial revert.
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
Documentation/memory-barriers.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index c4ddfcd..c1ebe99 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -851,7 +851,7 @@ demonstrated by two related examples, with the initial values of
CPU 0 CPU 1
======================= =======================
r1 = READ_ONCE(x); r2 = READ_ONCE(y);
- if (r1 > 0) if (r2 > 0)
+ if (r1 >= 0) if (r2 >= 0)
WRITE_ONCE(y, 1); WRITE_ONCE(x, 1);
assert(!(r1 == 1 && r2 == 1));
--
2.7.4
next reply other threads:[~2017-07-17 8:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-17 8:24 Akira Yokosawa [this message]
2017-07-19 17:43 ` Paul E. McKenney
2017-07-19 21:33 ` Akira Yokosawa
2017-07-19 21:56 ` Paul E. McKenney
2017-07-20 1:31 ` Boqun Feng
2017-07-20 5:47 ` Paul E. McKenney
2017-07-20 6:14 ` Boqun Feng
2017-07-20 12:52 ` Paul E. McKenney
2017-07-20 12:55 ` Akira Yokosawa
2017-07-20 16:11 ` Paul E. McKenney
2017-07-20 21:12 ` Akira Yokosawa
2017-07-20 21:42 ` Paul E. McKenney
2017-07-20 22:52 ` Akira Yokosawa
2017-07-20 23:07 ` Paul E. McKenney
2017-07-21 0:24 ` Boqun Feng
2017-07-21 16:31 ` Paul E. McKenney
2017-07-21 23:38 ` Akira Yokosawa
2017-07-23 4:43 ` Paul E. McKenney
2017-07-23 15:39 ` Boqun Feng
2017-07-24 0:04 ` Akira Yokosawa
2017-07-24 4:36 ` Paul E. McKenney
2017-07-24 6:34 ` Boqun Feng
2017-07-24 10:47 ` Akira Yokosawa
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=0d60072f-3848-a2b7-ce18-e1ed317b5c09@gmail.com \
--to=akiyks@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.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
Powered by JetHome