[PATCH 0/2] locking: fixup trivial nitpicks

[PATCH 0/2] locking: fixup trivial nitpicks

[SeongJae Park]

This patchset contains fixup of trivial nitpickes that found during translation
of locking/ directory.

SeongJae Park (2):
  locking: use consistent expressions
  locking: fix typos

 locking/locking.tex | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

-- 
1.9.1

[PATCH 1/2] locking: use consistent expressions

[SeongJae Park]

Few sentences are using inconsistent reference expressions.  This commit
modifies those sentences to use more consistent expressions.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 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

[PATCH 2/2] locking: fix typos

[SeongJae Park]

This commit fixes trivial typos.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 locking/locking.tex | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/locking/locking.tex b/locking/locking.tex
index a313284..e8ff812 100644
--- a/locking/locking.tex
+++ b/locking/locking.tex
@@ -242,7 +242,7 @@ containing locks from both the library and the caller.
 		deadlock cycle involving both caller and library locks.
 	\item	If one of the library functions returns a pointer to
 		a lock that is acquired by the caller, and if the
-		caller acquires one if its locks while holding the
+		caller acquires one of its locks while holding the
 		library's lock, we could again have a deadlock
 		cycle involving both caller and library locks.
 	\item	If one of the library functions acquires a lock and
@@ -1599,7 +1599,7 @@ Either way, line~21 releases the root \co{rcu_node} structure's
 This function illustrates the not-uncommon pattern of hierarchical
 locking.
 This pattern is quite difficult to implement using RAII locking,
-just like the interator encapsulation noted earlier,
+just like the iterator encapsulation noted earlier,
 and so the lock/unlock primitives will be needed for the foreseeable
 future.

@@ -1690,7 +1690,7 @@ Line~14 atomically exchanges the value zero (``unlocked'') into
 the lock, thus marking it as having been released.

 \QuickQuiz{}
-	Why not simply store zero into the lock word on line 14 of
+	Why not simply store zero into the lock word on line~14 of
 	Figure~\ref{fig:locking:Sample Lock Based on Atomic Exchange}?
 \QuickQuizAnswer{
 	This can be a legitimate implementation, but only if
-- 
1.9.1

Re: [PATCH 0/2] locking: fixup trivial nitpicks

[Paul E. McKenney]

On Thu, May 19, 2016 at 07:53:58AM +0900, SeongJae Park wrote:
> This patchset contains fixup of trivial nitpickes that found during translation
> of locking/ directory.

Queued and pushed, thank you!

On future submissions, could you please capitalize the word in the
subject line following the ":", as shown below?  (I have been fixing
them manually.)

							Thanx, Paul

> SeongJae Park (2):
>   locking: use consistent expressions
    locking: Use consistent expressions
>   locking: fix typos
    locking: Fix typos
> 
>  locking/locking.tex | 38 +++++++++++++++++++-------------------
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> -- 
> 1.9.1
> 

Re: [PATCH 0/2] locking: fixup trivial nitpicks

[SeongJae Park]

On Thu, May 19, 2016 at 9:33 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Thu, May 19, 2016 at 07:53:58AM +0900, SeongJae Park wrote:
>> This patchset contains fixup of trivial nitpickes that found during translation
>> of locking/ directory.
>
> Queued and pushed, thank you!
>
> On future submissions, could you please capitalize the word in the
> subject line following the ":", as shown below?  (I have been fixing
> them manually.)

Ok, I will!


Thanks,
SeongJae Park

>
>                                                         Thanx, Paul
>
>> SeongJae Park (2):
>>   locking: use consistent expressions
>     locking: Use consistent expressions
>>   locking: fix typos
>     locking: Fix typos
>>
>>  locking/locking.tex | 38 +++++++++++++++++++-------------------
>>  1 file changed, 19 insertions(+), 19 deletions(-)
>>
>> --
>> 1.9.1
>>
>