Fix subject-verb agreement, singular/plural forms, pronoun agreement, and countability in Chapter 9 prose.
These wording-only edits improve readability without changing technical meaning. Signed-off-by: Kunwu Chan <[email protected]> --- defer/defer.tex | 2 +- defer/rcu.tex | 2 +- defer/rcuapi.tex | 2 +- defer/rcufundamental.tex | 2 +- defer/rcuusage.tex | 4 ++-- defer/whichtochoose.tex | 10 +++++----- 6 files changed, 11 insertions(+), 11 deletions(-) diff --git a/defer/defer.tex b/defer/defer.tex index eefb1215..3a24ee5d 100644 --- a/defer/defer.tex +++ b/defer/defer.tex @@ -87,7 +87,7 @@ interface~3, and address~17 to interface~7. This list will normally be searched frequently and updated rarely. In \cref{chp:Hardware and its Habits} we learned that the best ways to evade inconvenient laws of physics, such as -the finite speed of light and the atomic nature of matter, is to +the finite speed of light and the atomic nature of matter, are to either partition the data or to rely on read-mostly sharing. This chapter applies read-mostly sharing techniques to Pre-BSD packet routing. diff --git a/defer/rcu.tex b/defer/rcu.tex index 13078687..9d812d77 100644 --- a/defer/rcu.tex +++ b/defer/rcu.tex @@ -16,7 +16,7 @@ use explicit counters to defer actions that could disturb readers, which results in read-side contention and thus poor scalability. The hazard pointers covered by \cref{sec:defer:Hazard Pointers} -uses implicit counters in the guise of per-thread lists of pointer. +use implicit counters in the guise of per-thread lists of pointers. This avoids read-side contention, but requires readers to do stores and conditional branches, as well as either \IXhpl{full}{memory barrier} in read-side primitives or real-time-unfriendly \IXacrlpl{ipi} in diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex index 4e231e5a..09e7c277 100644 --- a/defer/rcuapi.tex +++ b/defer/rcuapi.tex @@ -599,7 +599,7 @@ to reuse during the grace period that otherwise would have allowed them to be freed. Although this can be handled through careful use of flags that interact with the RCU callback queued by \co{call_rcu()}, this can be inconvenient -and can waste CPU times due to the overhead of the doomed \co{call_rcu()} +and can waste CPU time due to the overhead of the doomed \co{call_rcu()} invocations. In these cases, RCU's polled grace-period primitives can be helpful. diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex index ccfe9133..604381a9 100644 --- a/defer/rcufundamental.tex +++ b/defer/rcufundamental.tex @@ -11,7 +11,7 @@ independent of any particular example or use case. People who prefer to live their lives very close to the actual code may wish to skip the underlying fundamentals presented in this section. -The common use of RCU to protect linked data structure is comprised +The common use of RCU to protect linked data structures is comprised of three fundamental mechanisms, the first being used for insertion, the second being used for deletion, and the third being used to allow readers to tolerate concurrent insertions and deletions. diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex index 2bbd4cef..36939300 100644 --- a/defer/rcuusage.tex +++ b/defer/rcuusage.tex @@ -156,7 +156,7 @@ that of the ideal synchronization-free workload. \cref{sec:cpu:Pipelined CPUs} carefully already knew all of this! - These counter-intuitive results of course means that any + These counter-intuitive results of course mean that any performance result on modern microprocessors must be subject to some skepticism. In theory, it really does not make sense to obtain performance @@ -241,7 +241,7 @@ As noted in \cref{sec:defer:RCU Fundamentals} an important component of RCU is a way of waiting for RCU readers to finish. One of -RCU's great strength is that it allows you to wait for each of +RCU's great strengths is that it allows you to wait for each of thousands of different things to finish without having to explicitly track each and every one of them, and without incurring the performance degradation, scalability limitations, complex deadlock diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex index a152b028..a11de412 100644 --- a/defer/whichtochoose.tex +++ b/defer/whichtochoose.tex @@ -102,8 +102,8 @@ and that there be sufficient pointers for each CPU or thread to track all the objects being referenced at any given time. Given that most hazard-pointer-based traversals require only a few hazard pointers, this is not normally a problem in practice. -Of course, sequence locks provides no pointer-traversal protection, -which is why it is normally used on static data. +Of course, sequence locks provide no pointer-traversal protection, +which is why they are normally used on static data. \QuickQuiz{ Why can't users dynamically allocate the hazard pointers as they @@ -124,7 +124,7 @@ RCU readers must therefore be relatively short in order to avoid running the system out of memory, with special-purpose implementations such as SRCU, Tasks RCU, and Tasks Trace RCU being exceptions to this rule. Again, sequence locks provide no pointer-traversal protection, -which is why it is normally used on static data. +which is why they are normally used on static data. The ``Need for Traversal Retries'' row tells whether a new reference to a given object may be acquired unconditionally, as it can with RCU, or @@ -319,7 +319,7 @@ Hazard pointers incur the overhead of a \IX{memory barrier} for each data element traversed, and sequence locks incur the overhead of a pair of memory barriers for each attempt to execute the critical section. -The overhead of RCU implementations vary from nothing to that of a pair of +The overhead of RCU implementations varies from nothing to that of a pair of memory barriers for each read-side critical section, thus providing RCU with the best performance, particularly for read-side critical sections that traverse many data elements. @@ -622,7 +622,7 @@ Stjepan Glavina merged an epoch-based RCU implementation into the \co{crossbeam} set of concurrency-support ``crates'' for the Rust language~\cite{StjepanGlavina2018RustRCU}. -Jason Donenfeld produced an RCU implementations as part of his port of +Jason Donenfeld produced an RCU implementation as part of his port of WireGuard to Windows~NT kernel~\cite{JasonDonenfeld2021:WindowsNTwireguardRCU}. Finally, any garbage-collected concurrent language (not just Go!\@) gets -- 2.25.1
