Few sentences are using inconsistent reference expressions. This commit
modifies those sentences to use more consistent expressions.
Signed-off-by: SeongJae Park <sj38.park@xxxxxxxxx>
---
locking/locking.tex | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/locking/locking.tex b/locking/locking.tex
index c15e532..a313284 100644
--- a/locking/locking.tex
+++ b/locking/locking.tex
@@ -18,7 +18,7 @@ shared-memory parallel software is played by, you guessed it, locking.
This chapter will look into this dichotomy between villain and
hero, as fancifully depicted in
Figures~\ref{fig:locking:Locking: Villain or Slob?}
-and~Figure~\ref{fig:locking:Locking: Workhorse or Hero?}.
+and~\ref{fig:locking:Locking: Workhorse or Hero?}.
There are a number of reasons behind this Jekyll-and-Hyde dichotomy:
@@ -308,11 +308,11 @@ To see the benefits of local locking hierarchies, compare
Figures~\ref{fig:lock:Without Local Locking Hierarchy for qsort()} and
\ref{fig:lock:Local Locking Hierarchy for qsort()}.
In both figures, application functions \co{foo()} and \co{bar()}
-invoke \co{qsort()} while holding locks~A and B, respectively.
+invoke \co{qsort()} while holding Locks~A and B, respectively.
Because this is a parallel implementation of \co{qsort()}, it acquires
-lock~C.
+Lock~C.
Function \co{foo()} passes function \co{cmp()} to \co{qsort()},
-and \co{cmp()} acquires lock~B.
+and \co{cmp()} acquires Lock~B.
Function \co{bar()} passes a simple integer-comparison function (not
shown) to \co{qsort()}, and this simple function does not acquire any
locks.
@@ -323,15 +323,15 @@ Figure~\ref{fig:lock:Without Local Locking Hierarchy for qsort()},
deadlock can occur.
To see this, suppose that one thread invokes \co{foo()} while a second
thread concurrently invokes \co{bar()}.
-The first thread will acquire lock~A and the second thread will acquire
-lock~B.
-If the first thread's call to \co{qsort()} acquires lock~C, then it
-will be unable to acquire lock~B when it calls \co{cmp()}.
-But the first thread holds lock~C, so the second thread's call to
+The first thread will acquire Lock~A and the second thread will acquire
+Lock~B.
+If the first thread's call to \co{qsort()} acquires Lock~C, then it
+will be unable to acquire Lock~B when it calls \co{cmp()}.
+But the first thread holds Lock~C, so the second thread's call to
\co{qsort()} will be unable to acquire it, and thus unable to release
-lock~B, resulting in deadlock.
+Lock~B, resulting in deadlock.
-In contrast, if \co{qsort()} releases lock~C before invoking the
+In contrast, if \co{qsort()} releases Lock~C before invoking the
comparison function (which is unknown code from \co{qsort()}'s perspective,
then deadlock is avoided as shown in
Figure~\ref{fig:lock:Local Locking Hierarchy for qsort()}.
@@ -358,11 +358,11 @@ In this case, we cannot construct a local locking hierarchy by
releasing all locks before invoking unknown code.
However, we can instead construct a layered locking hierarchy, as shown in
Figure~\ref{fig:lock:Layered Locking Hierarchy for qsort()}.
-Here, the \co{cmp()} function uses a new lock~D that is acquired after
-all of locks~A, B, and C, avoiding deadlock.
-We therefore have three layers to the global deadlock hierarchy, the
-first containing locks~A and B, the second containing lock~C, and
-the third containing lock~D.
+here, the \co{cmp()} function uses a new Lock~D that is acquired after
+all of Locks~A, B, and C, avoiding deadlock.
+we therefore have three layers to the global deadlock hierarchy, the
+first containing Locks~A and B, the second containing Lock~C, and
+the third containing Lock~D.
\begin{figure}[tbp]
{ \scriptsize
--
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
