In the first example in the memory-barriers.txt file, CPU 2 is assigned to
run (x = B; y = A;). However, the rest of the example proceeds as if CPU 2 had been
running (x = A; y = B;) as shown by the descriptions of the possible executions:
STORE A=3, STORE B=4, x=LOAD A->3, y=LOAD B->4
STORE A=3, STORE B=4, y=LOAD B->4, x=LOAD A->3
STORE A=3, x=LOAD A->3, STORE B=4, y=LOAD B->4
STORE A=3, x=LOAD A->3, y=LOAD B->2, STORE B=4
STORE A=3, y=LOAD B->2, STORE B=4, x=LOAD A->3
STORE A=3, y=LOAD B->2, x=LOAD A->3, STORE B=4
STORE B=4, STORE A=3, x=LOAD A->3, y=LOAD B->4
STORE B=4, ...
...
The change was merely to make the inital evironment consistent with what happens in the
rest of the example.
Signed-off-by: Ganesh Rapolu <ganesh.rapolu@xxxxxxxxxxx>
---
Documentation/memory-barriers.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a4de88f..9a46bbe 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -115,8 +115,8 @@ For example, consider the following sequence of events:
CPU 1 CPU 2
=============== ===============
{ A == 1; B == 2 }
- A = 3; x = B;
- B = 4; y = A;
+ A = 3; x = A;
+ B = 4; y = B;
The set of accesses as seen by the memory system in the middle can be arranged
in 24 different combinations:
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
