lkml.org 
[lkml]   [2016]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[PATCH locking/Documentation 2/2] No speculated stores
This commit reworks an erroneous example that claims that dependency
barriers are needed to prevent speculation of dependent stores.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
Documentation/memory-barriers.txt | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a57679ec9441..b6307139b81a 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -598,7 +598,9 @@ between the address load and the data load:
This enforces the occurrence of one of the two implications, and prevents the
third possibility from arising.

-A data-dependency barrier must also order against dependent writes:
+However, writes are never speculated, so it is not necessary (but is
+good documentation practice) to use data-dependency barrier to order
+against dependent writes:

CPU 1 CPU 2
=============== ===============
@@ -607,11 +609,11 @@ A data-dependency barrier must also order against dependent writes:
<write barrier>
WRITE_ONCE(P, &B);
Q = READ_ONCE(P);
- <data dependency barrier>
*Q = 5;

-The data-dependency barrier must order the read into Q with the store
-into *Q. This prohibits this outcome:
+The prohibition against speculating writes means that even without a
+data-dependency barrier, the system must order the read into Q with the
+store into *Q. This prohibits this outcome:

(Q == &B) && (B == 4)

--
2.5.2
\
 
 \ /
  Last update: 2016-09-29 17:55    [W:2.279 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site