In the memory barrier document, improve the example of the data dependency
barrier situation by:
(1) showing the initial values of the variables involved; and
(2) repeating the instruction sequence description, this time with the data
dependency barrier actually shown to make it clear what the revised
sequence actually is.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
warthog>diffstat -p1 /tmp/mb.diff
Documentation/memory-barriers.txt | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index f855031..822fc45 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -610,6 +610,7 @@ loads. Consider the following sequence
CPU 1 CPU 2
======================= =======================
+ { B = 7; X = 9; Y = 8; C = &Y }
STORE A = 1
STORE B = 2
<write barrier>
@@ -651,7 +652,20 @@ In the above example, CPU 2 perceives th
(which would be B) coming after the the LOAD of C.
If, however, a data dependency barrier were to be placed between the load of C
-and the load of *C (ie: B) on CPU 2, then the following will occur:
+and the load of *C (ie: B) on CPU 2:
+
+ CPU 1 CPU 2
+ ======================= =======================
+ { B = 7; X = 9; Y = 8; C = &Y }
+ STORE A = 1
+ STORE B = 2
+ <write barrier>
+ STORE C = &B LOAD X
+ STORE D = 4 LOAD C (gets &B)
+ <data dependency barrier>
+ LOAD *C (reads B)
+
+then the following will occur:
+-------+ : : : :
| | +------+ +-------+
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
