count: fix typos

This commit fix typos such as wrong spelling, missed or unnecessarily inserted words and characters in COUNTING section.

---
 count/count.tex | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

count/count.tex +10 -10

index 83b695f..8f69a10 100644
@@ -672,7 +672,7 @@ at the beginning of this chapter.
 	to reduce.
 	However, the worst case is unchanged because although the
 	counter \emph{could} move in either direction, the worst
-	case is whenthe read operation completes immediately,
+	case is when the read operation completes immediately,
 	but then is delayed for $\Delta$ time units, during which
 	time all the changes in the counter's value move it in
 	the same direction, again giving us an absolute error

@@ -851,7 +851,7 @@ comes at the cost of the additional thread running \co{eventual()}.
 	the per-thread \co{counter} variables
 	might need to be limited to 32 bits in order to sum them accurately,
 	but with a 64-bit \co{global_count} variable to avoid overflow.
-	In this case, it is necessary to zero the per-thead
+	In this case, it is necessary to zero the per-thread
 	\co{counter} variables periodically in order to avoid overflow.
 	It is extremely important to note that this zeroing cannot
 	be delayed too long or overflow of the smaller per-thread

@@ -1648,7 +1648,7 @@ Then line~34 releases \co{gblcnt_mutex}, and line~35 returns success.
 
 Lines~38-50 show \co{read_count()}, which returns the aggregate value
 of the counter.
-It acquires \co{gblcnt_mutex} on line~43 and releases it on line 48,
+It acquires \co{gblcnt_mutex} on line~43 and releases it on line~48,
 excluding global operations from \co{add_count()} and \co{sub_count()},
 and, as we will see, also excluding thread creation and exit.
 Line~44 initializes local variable \co{sum} to the value of

@@ -2262,7 +2262,7 @@ then line~25 returns failure.
 
 Otherwise, line~28 adds \co{delta} to the global counter, line~29
 spreads counts to the local state if appropriate, line~30 releases
-\co{gblcnt_mutex} (again, as noted earlier), and finally, line 31
+\co{gblcnt_mutex} (again, as noted earlier), and finally, line~31
 returns success.
 
 Lines~34-63 of

@@ -2305,7 +2305,7 @@ Line~9 acquires \co{gblcnt_mutex} and line~16 releases it.
 Line~10 initializes local variable \co{sum} to the value of
 \co{globalcount}, and the loop spanning lines~11-15 adds the
 per-thread counters to this sum, isolating each per-thread counter
-using \co{split_ctrandmax} on line 13.
+using \co{split_ctrandmax} on line~13.
 Finally, line~17 returns the sum.
 
 \begin{figure}[tbp]

@@ -2432,7 +2432,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
 \QuickQuiz{}
 	What stops a thread from simply refilling its
 	\co{ctrandmax} variable immediately after
-	\co{flush_local_count()} on line 14 of
+	\co{flush_local_count()} on line~14 of
 	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
 	empties it?
 \QuickQuizAnswer{

@@ -2449,7 +2449,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
 	What prevents concurrent execution of the fastpath of either
 	\co{add_count()} or \co{sub_count()} from interfering with
 	the \co{ctrandmax} variable while
-	\co{flush_local_count()} is accessing it on line 27 of
+	\co{flush_local_count()} is accessing it on line~27 of
 	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
 	empties it?
 \QuickQuizAnswer{

@@ -2542,7 +2542,7 @@ Even though per-thread state will now be manipulated only by the
 corresponding thread, there will still need to be synchronization
 with the signal handlers.
 This synchronization is provided by the state machine shown in
-Figure~\ref{fig:count:Signal-Theft State Machine}
+Figure~\ref{fig:count:Signal-Theft State Machine}.
 The state machine starts out in the IDLE state, and when \co{add_count()}
 or \co{sub_count()} find that the combination of the local thread's count
 and the global count cannot accommodate the request, the corresponding

@@ -3576,7 +3576,7 @@ Summarizing the summary:
 	counters' partitioned updates and non-partitioned reads), but also
 	across time (as in
 	Section~\ref{sec:count:Approximate Limit Counters}'s and
-	Section~\ref{sec:count:Exact Limit Counters}'s and
+	Section~\ref{sec:count:Exact Limit Counters}'s
 	limit counters running fast when far from
 	the limit, but slowly when close to the limit).
 \item	Partitioning across time often batches updates locally

@@ -3585,7 +3585,7 @@ Summarizing the summary:
 	improving performance and scalability.
 	All the algorithms shown in
 	Tables~\ref{tab:count:Statistical Counter Performance on Power-6}
-	and~\ref{tab:count:Limit Counter Performance on Power-6}?
+	and~\ref{tab:count:Limit Counter Performance on Power-6}
 	make heavy use of batching.
 \item	Read-only code paths should remain read-only:  Spurious
 	synchronization writes to shared memory kill performance

Signature · 1 line

1.9.1

Quoted 2 lines · SeongJae Park

This commit fix typos such as wrong spelling, missed or unnecessarily inserted words and characters in COUNTING section.

Could you please resend with your Signed-off-by? Looks good otherwise.

Thanx, Paul

Quoted 101 lines

---
 count/count.tex | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

count/count.tex +10 -11

index 83b695f..8f69a10 100644
@@ -672,7 +672,7 @@ at the beginning of this chapter.
      to reduce.
      However, the worst case is unchanged because although the
      counter \emph{could} move in either direction, the worst
-     case is whenthe read operation completes immediately,
+     case is when the read operation completes immediately,
      but then is delayed for $\Delta$ time units, during which
      time all the changes in the counter's value move it in
      the same direction, again giving us an absolute error

@@ -851,7 +851,7 @@ comes at the cost of the additional thread running \co{eventual()}.
      the per-thread \co{counter} variables
      might need to be limited to 32 bits in order to sum them accurately,
      but with a 64-bit \co{global_count} variable to avoid overflow.
-     In this case, it is necessary to zero the per-thead
+     In this case, it is necessary to zero the per-thread
      \co{counter} variables periodically in order to avoid overflow.
      It is extremely important to note that this zeroing cannot
      be delayed too long or overflow of the smaller per-thread

@@ -1648,7 +1648,7 @@ Then line~34 releases \co{gblcnt_mutex}, and line~35 returns success.
 
 Lines~38-50 show \co{read_count()}, which returns the aggregate value
 of the counter.
-It acquires \co{gblcnt_mutex} on line~43 and releases it on line 48,
+It acquires \co{gblcnt_mutex} on line~43 and releases it on line~48,
 excluding global operations from \co{add_count()} and \co{sub_count()},
 and, as we will see, also excluding thread creation and exit.
 Line~44 initializes local variable \co{sum} to the value of

@@ -2262,7 +2262,7 @@ then line~25 returns failure.
 
 Otherwise, line~28 adds \co{delta} to the global counter, line~29
 spreads counts to the local state if appropriate, line~30 releases
-\co{gblcnt_mutex} (again, as noted earlier), and finally, line 31
+\co{gblcnt_mutex} (again, as noted earlier), and finally, line~31
 returns success.
 
 Lines~34-63 of

@@ -2305,7 +2305,7 @@ Line~9 acquires \co{gblcnt_mutex} and line~16 releases it.
 Line~10 initializes local variable \co{sum} to the value of
 \co{globalcount}, and the loop spanning lines~11-15 adds the
 per-thread counters to this sum, isolating each per-thread counter
-using \co{split_ctrandmax} on line 13.
+using \co{split_ctrandmax} on line~13.
 Finally, line~17 returns the sum.
 
 \begin{figure}[tbp]

@@ -2432,7 +2432,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
 \QuickQuiz{}
      What stops a thread from simply refilling its
      \co{ctrandmax} variable immediately after
-     \co{flush_local_count()} on line 14 of
+     \co{flush_local_count()} on line~14 of
      Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
      empties it?
 \QuickQuizAnswer{

@@ -2449,7 +2449,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
      What prevents concurrent execution of the fastpath of either
      \co{add_count()} or \co{sub_count()} from interfering with
      the \co{ctrandmax} variable while
-     \co{flush_local_count()} is accessing it on line 27 of
+     \co{flush_local_count()} is accessing it on line~27 of
      Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
      empties it?
 \QuickQuizAnswer{

@@ -2542,7 +2542,7 @@ Even though per-thread state will now be manipulated only by the
 corresponding thread, there will still need to be synchronization
 with the signal handlers.
 This synchronization is provided by the state machine shown in
-Figure~\ref{fig:count:Signal-Theft State Machine}
+Figure~\ref{fig:count:Signal-Theft State Machine}.
 The state machine starts out in the IDLE state, and when \co{add_count()}
 or \co{sub_count()} find that the combination of the local thread's count
 and the global count cannot accommodate the request, the corresponding

@@ -3576,7 +3576,7 @@ Summarizing the summary:
      counters' partitioned updates and non-partitioned reads), but also
      across time (as in
      Section~\ref{sec:count:Approximate Limit Counters}'s and
-     Section~\ref{sec:count:Exact Limit Counters}'s and
+     Section~\ref{sec:count:Exact Limit Counters}'s
      limit counters running fast when far from
      the limit, but slowly when close to the limit).
 \item        Partitioning across time often batches updates locally

@@ -3585,7 +3585,7 @@ Summarizing the summary:
      improving performance and scalability.
      All the algorithms shown in
      Tables~\ref{tab:count:Statistical Counter Performance on Power-6}
-     and~\ref{tab:count:Limit Counter Performance on Power-6}?
+     and~\ref{tab:count:Limit Counter Performance on Power-6}
      make heavy use of batching.
 \item        Read-only code paths should remain read-only:  Spurious
      synchronization writes to shared memory kill performance
--

1.9.1

This commit fix typos such as wrong spelling, missed or unnecessarily inserted words and characters in COUNTING section.

Signed-off-by SeongJae Park <[email protected]>

---
 count/count.tex | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

count/count.tex +10 -10

index 83b695f..8f69a10 100644
@@ -672,7 +672,7 @@ at the beginning of this chapter.
 	to reduce.
 	However, the worst case is unchanged because although the
 	counter \emph{could} move in either direction, the worst
-	case is whenthe read operation completes immediately,
+	case is when the read operation completes immediately,
 	but then is delayed for $\Delta$ time units, during which
 	time all the changes in the counter's value move it in
 	the same direction, again giving us an absolute error

@@ -851,7 +851,7 @@ comes at the cost of the additional thread running \co{eventual()}.
 	the per-thread \co{counter} variables
 	might need to be limited to 32 bits in order to sum them accurately,
 	but with a 64-bit \co{global_count} variable to avoid overflow.
-	In this case, it is necessary to zero the per-thead
+	In this case, it is necessary to zero the per-thread
 	\co{counter} variables periodically in order to avoid overflow.
 	It is extremely important to note that this zeroing cannot
 	be delayed too long or overflow of the smaller per-thread

@@ -1648,7 +1648,7 @@ Then line~34 releases \co{gblcnt_mutex}, and line~35 returns success.
 
 Lines~38-50 show \co{read_count()}, which returns the aggregate value
 of the counter.
-It acquires \co{gblcnt_mutex} on line~43 and releases it on line 48,
+It acquires \co{gblcnt_mutex} on line~43 and releases it on line~48,
 excluding global operations from \co{add_count()} and \co{sub_count()},
 and, as we will see, also excluding thread creation and exit.
 Line~44 initializes local variable \co{sum} to the value of

@@ -2262,7 +2262,7 @@ then line~25 returns failure.
 
 Otherwise, line~28 adds \co{delta} to the global counter, line~29
 spreads counts to the local state if appropriate, line~30 releases
-\co{gblcnt_mutex} (again, as noted earlier), and finally, line 31
+\co{gblcnt_mutex} (again, as noted earlier), and finally, line~31
 returns success.
 
 Lines~34-63 of

@@ -2305,7 +2305,7 @@ Line~9 acquires \co{gblcnt_mutex} and line~16 releases it.
 Line~10 initializes local variable \co{sum} to the value of
 \co{globalcount}, and the loop spanning lines~11-15 adds the
 per-thread counters to this sum, isolating each per-thread counter
-using \co{split_ctrandmax} on line 13.
+using \co{split_ctrandmax} on line~13.
 Finally, line~17 returns the sum.
 
 \begin{figure}[tbp]

@@ -2432,7 +2432,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
 \QuickQuiz{}
 	What stops a thread from simply refilling its
 	\co{ctrandmax} variable immediately after
-	\co{flush_local_count()} on line 14 of
+	\co{flush_local_count()} on line~14 of
 	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
 	empties it?
 \QuickQuizAnswer{

@@ -2449,7 +2449,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
 	What prevents concurrent execution of the fastpath of either
 	\co{add_count()} or \co{sub_count()} from interfering with
 	the \co{ctrandmax} variable while
-	\co{flush_local_count()} is accessing it on line 27 of
+	\co{flush_local_count()} is accessing it on line~27 of
 	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
 	empties it?
 \QuickQuizAnswer{

@@ -2542,7 +2542,7 @@ Even though per-thread state will now be manipulated only by the
 corresponding thread, there will still need to be synchronization
 with the signal handlers.
 This synchronization is provided by the state machine shown in
-Figure~\ref{fig:count:Signal-Theft State Machine}
+Figure~\ref{fig:count:Signal-Theft State Machine}.
 The state machine starts out in the IDLE state, and when \co{add_count()}
 or \co{sub_count()} find that the combination of the local thread's count
 and the global count cannot accommodate the request, the corresponding

@@ -3576,7 +3576,7 @@ Summarizing the summary:
 	counters' partitioned updates and non-partitioned reads), but also
 	across time (as in
 	Section~\ref{sec:count:Approximate Limit Counters}'s and
-	Section~\ref{sec:count:Exact Limit Counters}'s and
+	Section~\ref{sec:count:Exact Limit Counters}'s
 	limit counters running fast when far from
 	the limit, but slowly when close to the limit).
 \item	Partitioning across time often batches updates locally

@@ -3585,7 +3585,7 @@ Summarizing the summary:
 	improving performance and scalability.
 	All the algorithms shown in
 	Tables~\ref{tab:count:Statistical Counter Performance on Power-6}
-	and~\ref{tab:count:Limit Counter Performance on Power-6}?
+	and~\ref{tab:count:Limit Counter Performance on Power-6}
 	make heavy use of batching.
 \item	Read-only code paths should remain read-only:  Spurious
 	synchronization writes to shared memory kill performance

Signature · 1 line

1.9.1