>From ad3fca471bd3a6178f7988bbe5c9ab903f86722a Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@xxxxxxxxx>
Date: Mon, 13 Mar 2017 20:50:56 +0900
Subject: [PATCH v2 6/6] advsync/memorybarriers: Distinguish 'CPU family' from 'CPU'
In these paragraphs, "CPU" stands for either "CPU core" or
"CPU family". Explicitly use "CPU family" for the latter.
Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
---
advsync/memorybarriers.tex | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 85e9162..15ed1f6 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -415,11 +415,11 @@ If you just want to be told what the rules are rather than suffering
through the actual derivation,
please feel free to skip to Section~\ref{sec:advsync:A Few Simple Rules}.
-The exact semantics of memory barriers vary wildly from one CPU to
+The exact semantics of memory barriers vary wildly from one CPU family to
another, so portable code must rely only on the least-common-denominator
semantics of memory barriers.
-Fortunately, all CPUs impose the following rules:
+Fortunately, all CPU families impose the following rules:
\begin{enumerate}
\item All accesses by a given CPU will appear to that CPU to have
occurred in program order.
@@ -442,9 +442,9 @@ Each of these properties is described in the following sections.
A given CPU will see its own accesses as occurring in ``program order'',
as if the CPU was executing only one instruction at a time with no
reordering or speculation.
-For older CPUs, this restriction is necessary for binary compatibility,
+For older CPU families, this restriction is necessary for binary compatibility,
and only secondarily for the sanity of us software types.
-There have been a few CPUs that violate this rule to a limited extent,
+There have been a few CPU families that violate this rule to a limited extent,
but in those cases, the compiler has been responsible
for ensuring that ordering is explicitly enforced as needed.
@@ -511,7 +511,7 @@ of an external logic analyzer
However, if CPU~2's access to B sees the result of CPU~1's access
to B, then CPU~2's access to A is guaranteed to see the result of
CPU~1's access to A.
-Although some CPUs' memory barriers do in fact provide stronger,
+Although some CPU families' memory barriers do in fact provide stronger,
unconditional ordering guarantees, portable code may rely only
on this weaker if-then conditional ordering guarantee.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
