>From 98c6fbbe2a7b04bc1ad11d70d96995425d8635de Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@xxxxxxxxx>
Date: Wed, 24 Aug 2016 20:41:41 +0900
Subject: [PATCH 3/3] locking: Typo fixes
Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
---
locking/locking.tex | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/locking/locking.tex b/locking/locking.tex
index 9eafcf5..48a3520 100644
--- a/locking/locking.tex
+++ b/locking/locking.tex
@@ -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
--
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
