Commit-ID: 37ef0341ca60b364dde05239c98b15c999195d8c Gitweb: http://git.kernel.org/tip/37ef0341ca60b364dde05239c98b15c999195d8c Author: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> AuthorDate: Mon, 25 Jan 2016 22:12:34 -0800 Committer: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> CommitDate: Mon, 14 Mar 2016 15:52:18 -0700 documentation: Add alternative release-acquire outcome The memory-barriers.txt discussion of local transitivity and release-acquire chains leaves out discussion of the outcome of the read from "u". This commit therefore adds an outcome showing that you can get a "1" from this read even if the release-acquire pairs don't line up. Reported-by: Will Deacon <will.deacon@xxxxxxx> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> --- Documentation/memory-barriers.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index ae9d306..57e4a4b 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1372,6 +1372,10 @@ is possible: r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 +As an aside, the following outcome is also possible: + + r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 && r5 == 1 + Although cpu0(), cpu1(), and cpu2() will see their respective reads and writes in order, CPUs not involved in the release-acquire chain might well disagree on the order. This disagreement stems from the fact that -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|