[PATCH-perfbook] memorder: Fix typos

[PATCH-perfbook] memorder: Fix typos

[Johann Klähn]

Signed-off-by: Johann Klähn <johann@jklaehn.de>
---
 memorder/memorder.tex | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/memorder/memorder.tex b/memorder/memorder.tex
index 865eff95..9792099f 100644
--- a/memorder/memorder.tex
+++ b/memorder/memorder.tex
@@ -2169,7 +2169,7 @@ from a particular store, then, courtesy of the finite speed of light and
 the non-zero size of modern computing systems, the store absolutely has
 to have executed at an earlier time than did the load.
 This means that carefully constructed programs can rely on the
-passage of time itself as an memory-ordering operation.
+passage of time itself as a memory-ordering operation.
 
 \begin{figure}
 \centering
@@ -2588,7 +2588,7 @@ if (p == &reserve_int) {
 \item	Although it is permissible to compute offsets from a
 	pointer, these offsets must not result in total cancellation.
 	For example, given a \co{char} pointer \co{cp},
-	\co{cp-(uintptr_t)cp)} will cancel and can allow the compiler
+	\co{cp-(uintptr_t)cp} will cancel and can allow the compiler
 	to break your dependency chain.
 	On the other hand, canceling offset values with each other
 	is perfectly safe and legal.
@@ -2753,7 +2753,7 @@ void updater(void)		\lnlbl[upd:b]
 {
 	struct foo *p;
 
-	p = malloc(sizeo(*p));		\lnlbl[upd:alloc]
+	p = malloc(sizeof(*p));		\lnlbl[upd:alloc]
 	BUG_ON(!p);			\lnlbl[upd:bug]
 	p->a = 42;			\lnlbl[upd:init:a]
 	p->b = 43;
@@ -2803,7 +2803,7 @@ bitterly on \clnref{bug} if none is available.
 \Clnrefrange{init:a}{init:c} initialize the newly allocated structure,
 and then \clnref{assign1} assigns the pointer to \co{gp1}.
 \Clnref{upd:b,upd:c} then update two of the structure's fields, and does
-so \co{after} \clnref{assign1} has made those fields visible to readers.
+so \emph{after} \clnref{assign1} has made those fields visible to readers.
 Please note that unsynchronized update of reader-visible fields
 often constitutes a bug.
 Although there are legitimate use cases doing just this, such use cases
@@ -3032,7 +3032,7 @@ if (q || 1 > 0)
 
 Because the first condition cannot fault and the second condition is
 always true, the compiler can transform this example as following,
-defeating control dependency:
+defeating the control dependency:
 
 \begin{VerbatimN}
 q = READ_ONCE(x);
@@ -3238,7 +3238,7 @@ These facts are what enables the lockless fastpaths in
 \cref{lst:SMPdesign:Allocator-Cache Allocator Function,%
 lst:SMPdesign:Allocator-Cache Free Function},
 respectively.
-However, this also why the developer is responsible for providing
+However, this is also why the developer is responsible for providing
 appropriate ordering (for example, by using \co{smp_store_release()})
 when publishing a pointer to a newly allocated block of memory.
 After all, in the CPU-local case, the allocator has not necessarily
@@ -3307,7 +3307,7 @@ As it turns out, quite a bit:
 	Is some other CPU or thread not holding that lock guaranteed to
 	see A and B in order?
 \item	As above, but with the lock reacquisition carried out by some
-	other CPU or threads?
+	other CPU or thread?
 \item	As above, but with the lock reacquisition being some other lock?
 \item	What ordering guarantees are provided by \co{spin_is_locked()}?
 \end{enumerate}
@@ -3571,7 +3571,7 @@ One reason is modeling performance, as shown in
 on
 \cpageref{tab:formal:Locking: Modeling vs. Emulation Time (s)}.
 Directly modeling locking in general is orders of magnitude faster
-than modeling even a trivial implementation.
+than emulating even a trivial implementation.
 This should be no surprise, given the combinatorial explosion experienced
 by present-day formal-verification tools with increases in the number of
 memory accesses executed by the code being modeled.
-- 
2.34.1

Re: [PATCH-perfbook] memorder: Fix typos

[Paul E. McKenney]

On Thu, Feb 03, 2022 at 10:10:01PM +0100, Johann Klähn wrote:
> Signed-off-by: Johann Klähn <johann@jklaehn.de>

Good catches, queued and pushed, thank you!

							Thanx, Paul

> ---
>  memorder/memorder.tex | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/memorder/memorder.tex b/memorder/memorder.tex
> index 865eff95..9792099f 100644
> --- a/memorder/memorder.tex
> +++ b/memorder/memorder.tex
> @@ -2169,7 +2169,7 @@ from a particular store, then, courtesy of the finite speed of light and
>  the non-zero size of modern computing systems, the store absolutely has
>  to have executed at an earlier time than did the load.
>  This means that carefully constructed programs can rely on the
> -passage of time itself as an memory-ordering operation.
> +passage of time itself as a memory-ordering operation.
>  
>  \begin{figure}
>  \centering
> @@ -2588,7 +2588,7 @@ if (p == &reserve_int) {
>  \item	Although it is permissible to compute offsets from a
>  	pointer, these offsets must not result in total cancellation.
>  	For example, given a \co{char} pointer \co{cp},
> -	\co{cp-(uintptr_t)cp)} will cancel and can allow the compiler
> +	\co{cp-(uintptr_t)cp} will cancel and can allow the compiler
>  	to break your dependency chain.
>  	On the other hand, canceling offset values with each other
>  	is perfectly safe and legal.
> @@ -2753,7 +2753,7 @@ void updater(void)		\lnlbl[upd:b]
>  {
>  	struct foo *p;
>  
> -	p = malloc(sizeo(*p));		\lnlbl[upd:alloc]
> +	p = malloc(sizeof(*p));		\lnlbl[upd:alloc]
>  	BUG_ON(!p);			\lnlbl[upd:bug]
>  	p->a = 42;			\lnlbl[upd:init:a]
>  	p->b = 43;
> @@ -2803,7 +2803,7 @@ bitterly on \clnref{bug} if none is available.
>  \Clnrefrange{init:a}{init:c} initialize the newly allocated structure,
>  and then \clnref{assign1} assigns the pointer to \co{gp1}.
>  \Clnref{upd:b,upd:c} then update two of the structure's fields, and does
> -so \co{after} \clnref{assign1} has made those fields visible to readers.
> +so \emph{after} \clnref{assign1} has made those fields visible to readers.
>  Please note that unsynchronized update of reader-visible fields
>  often constitutes a bug.
>  Although there are legitimate use cases doing just this, such use cases
> @@ -3032,7 +3032,7 @@ if (q || 1 > 0)
>  
>  Because the first condition cannot fault and the second condition is
>  always true, the compiler can transform this example as following,
> -defeating control dependency:
> +defeating the control dependency:
>  
>  \begin{VerbatimN}
>  q = READ_ONCE(x);
> @@ -3238,7 +3238,7 @@ These facts are what enables the lockless fastpaths in
>  \cref{lst:SMPdesign:Allocator-Cache Allocator Function,%
>  lst:SMPdesign:Allocator-Cache Free Function},
>  respectively.
> -However, this also why the developer is responsible for providing
> +However, this is also why the developer is responsible for providing
>  appropriate ordering (for example, by using \co{smp_store_release()})
>  when publishing a pointer to a newly allocated block of memory.
>  After all, in the CPU-local case, the allocator has not necessarily
> @@ -3307,7 +3307,7 @@ As it turns out, quite a bit:
>  	Is some other CPU or thread not holding that lock guaranteed to
>  	see A and B in order?
>  \item	As above, but with the lock reacquisition carried out by some
> -	other CPU or threads?
> +	other CPU or thread?
>  \item	As above, but with the lock reacquisition being some other lock?
>  \item	What ordering guarantees are provided by \co{spin_is_locked()}?
>  \end{enumerate}
> @@ -3571,7 +3571,7 @@ One reason is modeling performance, as shown in
>  on
>  \cpageref{tab:formal:Locking: Modeling vs. Emulation Time (s)}.
>  Directly modeling locking in general is orders of magnitude faster
> -than modeling even a trivial implementation.
> +than emulating even a trivial implementation.
>  This should be no surprise, given the combinatorial explosion experienced
>  by present-day formal-verification tools with increases in the number of
>  memory accesses executed by the code being modeled.
> -- 
> 2.34.1
>