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(-)
diff --git a/count/count.tex b/count/count.tex
index 83b695f..8f69a10 100644
--- a/count/count.tex
+++ b/count/count.tex
@@ -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
--
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
