Typo fixes

index 25fea75..8f2767e 100644
@@ -192,8 +192,8 @@ This lock must also be released after line 13 in
 Figure~\ref{fig:app:questions:After Producer Function} and
 after line 17 in
 Figure~\ref{fig:app:questions:After Consumer Function}.
-These locks cause the code segments in line 10-13 of
-Figure~\ref{fig:app:questions:After Producer Function} and in line 13-17 of
+These locks cause the code segments in lines~10-13 of
+Figure~\ref{fig:app:questions:After Producer Function} and in lines~13-17 of
 Figure~\ref{fig:app:questions:After Consumer Function} to {\em exclude}
 each other, in other words, to run atomically with respect to each other.
 This is represented in

index 19e664b..bb7e0e3 100644
@@ -1049,7 +1049,7 @@ line~11 invokes \co{cpu_needs_another_gp()} to see if the current
 CPU has callbacks that need another RCU grace period to elapse,
 line~13 checks to see if the current grace period has ended,
 line~15 checks to see if a new grace period has started,
-and, finally, lines 17-22 check to see if it is time to attempt
+and, finally, lines~17-22 check to see if it is time to attempt
 to force holdout CPUs to pass through a quiescent state.
 This latter check breaks down as follows: (1) lines~17-18 check to see
 if there is a grace period in progress, and, if so, lines~19-22

@@ -2003,7 +2003,7 @@ If so, lines~31-38 move them.
 Line~31 splices the list of callbacks onto the end of the running CPU's
 list.
 Lines~32-33 sets the running CPU's callback tail pointer to that of
-the CPU going offline, and then lines 34-36 initialize the going-offline
+the CPU going offline, and then lines~34-36 initialize the going-offline
 CPU's list to be empty.
 Line~37 adds the length of the going-offline CPU's callback list to
 that of the currently running CPU, and, finally, line 38 zeroes the

@@ -3754,7 +3754,7 @@ to record a quiescent state for any that are currently in dynticks-idle
 state (but not currently in an irq or NMI handler).
 Lines~41-42 serve to inform gcc that this branch of the switch statement
 is dead code for non-\co{CONFIG_NO_HZ} kernels.
-Lines 43-45 invoke \co{rcu_process_dyntick()} in order to invoke
+Lines~43-45 invoke \co{rcu_process_dyntick()} in order to invoke
 \co{dyntick_save_progress_counter()} for each CPU that has not yet
 passed through a quiescent state for the current grace period,
 exiting \co{force_quiescent_state()} if the grace period ends in

@@ -3906,7 +3906,7 @@ duration, with line~14 invoking \co{print_other_cpu_stall()} if so.
 Figure~\ref{fig:app:rcuimpl:rcutreewt:Code for print-cpu-stall}
 shows the code for \co{print_cpu_stall()}.
 
-Line~6-11 prints a console message and dumps the current CPU's stack,
+Lines~6-11 prints a console message and dumps the current CPU's stack,
 while lines~12-17 compute the time to the next CPU stall warning, should
 the grace period stretch on that much additional time.
 

index 2bbd214..7c774c6 100644
@@ -351,7 +351,7 @@ could be accomplished without a reboot.
 
 The \co{readside()} function overlaps an RCU and an SRCU read-side
 critical section, with the former running from lines~5-11 and the
-latter running from lines 10-13.
+latter running from lines~10-13.
 The RCU read-side critical section uses Pure
 %
 % RCU\IfInBook{ (see Section~\ref{sec:advsync:Pure RCU})}

index c2110dc..2ee2db3 100644
@@ -1713,7 +1713,7 @@ code shown in
 Figure~\ref{fig:app:whymb:Insert and Lock-Free Search}.
 This \co{smp_wmb()} on line~9 of this figure
 guarantees that the element initialization
-in lines 6-8 is executed before the element is added to the
+in lines~6-8 is executed before the element is added to the
 list on line~10, so that the lock-free search will work correctly.
 That is, it makes this guarantee on all CPUs {\em except} Alpha.
 

index b86527f..c963da5 100644
@@ -275,7 +275,7 @@ arbitrary hash functions, with the key-comparison function passed in via
 \co{cmp()}, in a manner similar to \co{qsort()}.
 Line~11 maps from the hash value to a pointer to the corresponding
 hash bucket.
-Each pass through the loop spanning line~12-19 examines one element
+Each pass through the loop spanning lines~12-19 examines one element
 of the bucket's hash chain.
 Line~15 checks to see if the hash values match, and if not, line~16
 proceeds to the next element.

index f64639c..2cd8310 100644
@@ -1215,7 +1215,7 @@ to model an interrupt handler:
 \end{verbatim}
 }
 
-The loop from line~7-48 models up to \co{MAX_DYNTICK_LOOP_IRQ}
+The loop from lines~7-48 models up to \co{MAX_DYNTICK_LOOP_IRQ}
 interrupts, with lines~8 and 9 forming the loop condition and line~45
 incrementing the control variable.
 Line~10 tells \co{dyntick_nohz()} that an interrupt handler

153 lines not on this page · raw message

index 394475d..130faaf 100644
@@ -615,7 +615,7 @@ Lines~16-23 repeatedly check the value of \co{x}, printing the new value
 each time that it changes.
 Line~22 sleeps for one millisecond, which allows this demonstration
 to run nicely on a uniprocessor machine.
-Line~24-27 release the \co{pthread_mutex_t}, again checking for
+Lines~24-27 release the \co{pthread_mutex_t}, again checking for
 errors and exiting the program if any occur.
 Finally, line~28 returns \co{NULL}, again to match the function type
 required by \co{pthread_create()}.

index bb7e0e3..c9f2e9b 100644
@@ -3906,7 +3906,7 @@ duration, with line~14 invoking \co{print_other_cpu_stall()} if so.
 Figure~\ref{fig:app:rcuimpl:rcutreewt:Code for print-cpu-stall}
 shows the code for \co{print_cpu_stall()}.
 
-Lines~6-11 prints a console message and dumps the current CPU's stack,
+Lines~6-11 print a console message and dump the current CPU's stack,
 while lines~12-17 compute the time to the next CPU stall warning, should
 the grace period stretch on that much additional time.
 

index 9eafcf5..48a3520 100644
@@ -234,7 +234,7 @@ containing locks from both the library and the caller.
 	\begin{enumerate}
 	\item	If one of the library function's arguments is a pointer
 		to a lock that this library function acquires, and if
-		the library function holds one if its locks while
+		the library function holds one of its locks while
 		acquiring the caller's lock, then we could have a
 		deadlock cycle involving both caller and library locks.
 	\item	If one of the library functions returns a pointer to

@@ -469,7 +469,7 @@ Chapter~\ref{chp:Deferred Processing}.
 \subsubsection{Locking Hierarchies and Pointers to Locks}
 \label{sec:locking:Locking Hierarchies and Pointers to Locks}
 
-Althought there are some exceptions, an external API containing a pointer
+Although there are some exceptions, an external API containing a pointer
 to a lock is very often a misdesigned API.
 Handing an internal lock to some other software component is after all
 the antithesis of information hiding, which is in turn a key design

@@ -495,7 +495,7 @@ prevents hangs due to lost wakeups.
 \QuickQuizAnswer{
 	Absolutely not!
 
-	Consider the a program that acquires \co{mutex_a}, and then
+	Consider a program that acquires \co{mutex_a}, and then
 	\co{mutex_b}, in that order, and then passes \co{mutex_a}
 	to \co{pthread_cond_wait}.
 	Now, \co{pthread_cond_wait} will release \co{mutex_a}, but

@@ -622,7 +622,7 @@ must release the locks and start over.
 	the code will always retry, never making forward progress.
 	This is termed ``livelock'' if no thread makes any forward progress or
 	``starvation''
-	if some threads make forward progress but other do not
+	if some threads make forward progress but others do not
 	(see Section~\ref{sec:locking:Livelock and Starvation}).
 } \QuickQuizEnd