[PATCH 0/6] fix trivial problems in advanced synchronization chapter

[PATCH 0/6] fix trivial problems in advanced synchronization chapter

[SeongJae Park]

This patchset fixes trivial problems in `Advanced Synchronization` chapter that
found while translation.

SeongJae Park (6):
  advsync: fix trivial typos
  advsync: fix latex syntax related typos
  advsync: use latex reference feature consistently
  advsync: fix wrong code example
  advsync: fix critical section bleed-in description
  advsync: fix wrong reference to section ``MMIO write barrier''

 advsync/advsync.tex        |  8 ++++----
 advsync/memorybarriers.tex | 51 ++++++++++++++++++++++++----------------------
 2 files changed, 31 insertions(+), 28 deletions(-)

-- 
1.9.1

[PATCH 1/6] advsync: fix trivial typos

[SeongJae Park]

This commit fixes trivial typos under `advsync/` directory.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/advsync.tex        | 4 ++--
 advsync/memorybarriers.tex | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/advsync/advsync.tex b/advsync/advsync.tex
index 7250e96..118dc74 100644
--- a/advsync/advsync.tex
+++ b/advsync/advsync.tex
@@ -30,7 +30,7 @@ gives a brief overview of non-blocking synchronization.

 Although locking is the workhorse of parallelism in production, in
 many situations performance, scalability, and real-time response can
-all be greatly improved though use of lockless techniques.
+all be greatly improved through use of lockless techniques.
 A particularly impressive example of such a lockless technique are
 the statistical counters describe in
 Section~\ref{sec:count:Statistical Counters},
@@ -45,7 +45,7 @@ Other examples we have covered include:
 	Section~\ref{sec:SMPdesign:Resource Allocator Caches}.
 \item	The maze solver in Section~\ref{sec:SMPdesign:Beyond Partitioning}.
 \item	The data-ownership techniques described in
-	Section~\ref{chp:Data Ownership}.
+	Chapter~\ref{chp:Data Ownership}.
 \item	The reference-counting and RCU techinques described in
 	Chapter~\ref{chp:Deferred Processing}.
 \item	The lookup code paths described in Chapter~\ref{chp:Data Structures}.
diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 99e074d..c668f3c 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -759,7 +759,7 @@ these combinations in order to fully understand how this works.
 	it is not possible for one of the loads to see the
 	results of the other load.
 	However, if we know that CPU~2's load from B returned a
-	newer value than CPU~1's load from B, the we also know
+	newer value than CPU~1's load from B, then we also know
 	that CPU~2's load from A returned either the same value
 	as CPU~1's load from A or some later value.

@@ -1047,7 +1047,7 @@ a few simple rules:
 	by the first CPU, then the second CPU's load from A must
 	give the value stored by the first CPU.
 \item	If one CPU does a load from A ordered before a store to B,
-	and if a second CPU does a load from B ordered before a store from A,
+	and if a second CPU does a load from B ordered before a store to A,
 	and if the second CPU's load from B gives the value stored by
 	the first CPU, then the first CPU's load from A must \emph{not}
 	give the value stored by the second CPU.
-- 
1.9.1

[PATCH 2/6] advsync: fix latex syntax related typos

[SeongJae Park]

This commit fixes typos related with latex.  The typos include:
unnecessarily doubly inserted commas, missed tildes, missed dots,
wrongly located dot and question mark, unwrapped citation.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/advsync.tex        |  4 ++--
 advsync/memorybarriers.tex | 22 +++++++++++-----------
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/advsync/advsync.tex b/advsync/advsync.tex
index 118dc74..12bacbf 100644
--- a/advsync/advsync.tex
+++ b/advsync/advsync.tex
@@ -78,14 +78,14 @@ basis of real-time programming:
 \begin{enumerate}
 \item	Real-time forward-progress guarantees usually have some
 	definite time associated with them, for example,
-	``scheduling latency must be less than 100 microseconds.''
+	``scheduling latency must be less than 100 microseconds.''.
 	In contrast, the most popular forms of NBS only guarantees
 	that progress will be made in finite time, with no definite
 	bound.
 \item	Real-time forward-progress guarantees are sometimes
 	probabilistic, as in the soft-real-time guarantee that
 	``at least 99.9\% of the time, scheduling latency must
-	be less than 100 microseconds.''
+	be less than 100 microseconds.''.
 	In contrast, NBS's forward-progress
 	guarantees have traditionally been unconditional.
 \item	Real-time forward-progress guarantees are often conditioned on
diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index c668f3c..15de36a 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -37,7 +37,7 @@ appears to guarantee that the assertion never fires.
 After all, if \co{r1 != 1}, we might hope that Thread~1's load from \co{y}
 must have happened before Thread~2's store to \co{y}, which might raise
 further hopes that Thread~2's load from \co{x} must happen after
-Thread 1's store to \co{x}, so that \co{r2 == 1}, as required by the
+Thread~1's store to \co{x}, so that \co{r2 == 1}, as required by the
 assertion.
 The example is symmetric, so similar hopeful reasoning might lead
 us to hope that \co{r2 != 1} guarantees that \co{r1 == 1}.
@@ -295,7 +295,7 @@ over a 532-nanosecond time period, as shown in
 Figure~\ref{fig:advsync:A Variable With Multiple Simultaneous Values}.
 This data was collected on 1.5GHz POWER5 system with 8 cores, each containing
 a pair of hardware threads.
-CPUs~1, 2, 3, and 4 recorded the values, while CPU 0 controlled the test.
+CPUs~1, 2, 3, and 4 recorded the values, while CPU~0 controlled the test.
 The timebase counter period was about 5.32ns, sufficiently fine-grained
 to allow observations of intermediate cache states.

@@ -320,7 +320,7 @@ CPU~4 believes that the value is ``4'' for almost 500ns.

 \QuickQuiz{}
 	How could CPUs possibly have different views of the
-	value of a single variable \emph{at the same time?}
+	value of a single variable \emph{at the same time}?
 \QuickQuizAnswer{
 	Many CPUs have write buffers that record the values of
 	recent writes, which are applied once the corresponding
@@ -459,8 +459,8 @@ For example, in the following set of operations, CPU~1's access to
 A does not unconditionally precede its access to B from the viewpoint
 of an external logic analyzer
 \IfInBook{(see Appendix~\ref{chp:app:whymb:Why Memory Barriers?}
-	  for examples).
-	 }
+	  for examples)
+	 }.
 	 {(the system is only to act \emph{as if} the accesses
 	  are in order; it is not necessarily required to actually
 	  force them to be in order).}
@@ -1037,10 +1037,10 @@ a few simple rules:
 		for example, if a given CPU never loaded or stored
 		the shared variable, then it can have no opinion about
 		that variable's value.}
-\item	If one CPU does ordered stores to variables A and B,\footnote{
+\item	If one CPU does ordered stores to variables A and B\footnote{
 		For example, by executing the store to A, a
 		memory barrier, and then the store to B.},
-	and if a second CPU does ordered loads from B and A,\footnote{
+	and if a second CPU does ordered loads from B and A\footnote{
 		For example, by executing the load from B, a
 		memory barrier, and then the load from A.},
 	then if the second CPU's load from B gives the value stored
@@ -1903,9 +1903,9 @@ In the above example, CPU~2 perceives that \co{B} is 7,
 despite the load of \co{*C}
 (which would be \co{B}) coming after the \co{LOAD} of \co{C}.

-If, however, a data dependency barrier were to be placed between the load of C
-and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial values of
-{\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:
+If, however, a data dependency barrier were to be placed between the load of
+\co{C} and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial
+values of {\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:

 \vspace{5pt}
 \begin{minipage}[t]{\columnwidth}
@@ -2002,7 +2002,7 @@ Figure~\ref{fig:advsync:Read Barrier Supplied}.
 \end{figure*}

 To illustrate this more completely, consider what could happen if the code
-contained a load of A either side of the read barrier, once again
+contained a load of \co{A} either side of the read barrier, once again
 with the same initial values of
 {\tt \{A = 0, B = 9\}}:

-- 
1.9.1

[PATCH 3/6] advsync: use latex reference feature consistently

[SeongJae Park]

References to other sections in `Advanced Synchronization` chapter use
latex reference feature and section name direct citation inconsistently.
Because most other parts are using latex reference feature and it is
easier for document maintainance, it would be better to use latex
reference feature only.  For the reason, this commit enforces latex
reference feature to the references.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/memorybarriers.tex | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 15de36a..ee9312d 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -1454,7 +1454,8 @@ memory system as time progresses.  All stores before a write barrier will
 occur in the sequence \emph{before} all the stores after the write barrier.

 $\dagger$ Note that write barriers should normally be paired with read
-or data dependency barriers; see the ``SMP barrier pairing'' subsection.
+or data dependency barriers; see the
+Section~\ref{sec:advsync:SMP Barrier Pairing}.

 \paragraph{Data Dependency Barriers}

@@ -1479,19 +1480,19 @@ time the barrier completes, the effects of all the stores prior to that
 touched by the load will be perceptible to any loads issued after the data
 dependency barrier.

-See the ``Examples of memory barrier sequences'' subsection for diagrams
-showing the ordering constraints.
+See the Section~\ref{sec:advsync:Examples of Memory Barrier Pairings} for
+diagrams showing the ordering constraints.

 $\dagger$ Note that the first load really has to have a
 \emph{data} dependency and
 not a control dependency.  If the address for the second load is dependent
 on the first load, but the dependency is through a conditional rather than
 actually loading the address itself, then it's a \emph{control} dependency and
-a full read barrier or better is required.  See the ``Control dependencies''
-subsection for more information.
+a full read barrier or better is required.  See the
+Section~\ref{sec:advsync:Control Dependencies} for more information.

 $\dagger$ Note that data dependency barriers should normally be paired with
-write barriers; see the ``SMP barrier pairing'' subsection.
+write barriers; see the Section~\ref{sec:advsync:SMP Barrier Pairign}.

 \paragraph{Read Memory Barriers}

@@ -1593,7 +1594,8 @@ of the confines of a given architecture:
 \item	There is no guarantee that a CPU will see the correct order
 	of effects from a second CPU's accesses, even \emph{if} the second CPU
 	uses a memory barrier, unless the first CPU \emph{also} uses a matching
-	memory barrier (see the subsection on ``SMP Barrier Pairing'').
+	memory barrier (see the
+	Section~\ref{sec:advsync:SMP Barrier Pairing}).
 \item	There is no guarantee that some intervening piece of off-the-CPU
 	hardware\footnote{
 		This is of concern primarily in operating-system kernels.
-- 
1.9.1

[PATCH 4/6] advsync: fix wrong code example

[SeongJae Park]

The code means `Y = *(A + 4)` but it is written as `Y = *A`. This commit
fixes the typo.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/memorybarriers.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index ee9312d..b1f49d3 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
 \begin{minipage}[t]{\columnwidth}
 \scriptsize
 \begin{verbatim}
-*A = X; Y = *A;
+*A = X; Y = *(A + 4);
 \end{verbatim}
 \end{minipage}
 \vspace{5pt}
-- 
1.9.1

[PATCH 5/6] advsync: fix critical section bleed-in description

[SeongJae Park]

A sentence in `Locking Examples` section says both LOCK and UNLOCK
allows preceding operations `bleed in` to the critical section.
However, it's wrong description.  LOCK allows only preceding operations
and UNLOCK allows only following operations to bleed in.  Looks like the
wrong description made by just a trivial mistake.  This commit fixes the
sentence to have correct description.

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

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index b1f49d3..1fe0953 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2232,8 +2232,9 @@ might well execute in the following order:
 \end{minipage}
 \vspace{5pt}

-Again, always remember that both LOCK and UNLOCK are permitted to let
-preceding operations ``bleed in'' to the critical section.
+Again, always remember that LOCK and UNLOCK are permitted to let preceding
+operations and following operations ``bleed in'' to the critical section
+respectively.

 \QuickQuiz{}
 	What sequence of LOCK-UNLOCK operations \emph{would}
-- 
1.9.1

[PATCH 6/6] advsync: fix wrong reference to section ``MMIO write barrier''

[SeongJae Park]

A sentence references ``MMIO write barrier'' subsection though the
section does not exists.  Unfortunately, there is no section for MMIO
write barrier though appendix ``Why Memory Barriers?'' says about
mmiowb() subtly.  For the purpose of the sentence, it could be
alternated with reference to ``Device operations'' subsection because it
describes about the exceptional case.  For the reason, this commit
updates it to the reference to ``Device Operations'' subsection.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/memorybarriers.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 1fe0953..b511f51 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -1559,7 +1559,7 @@ other strictly in the order specified.

 The use of LOCK and UNLOCK operations generally precludes the need for
 other sorts of memory barrier (but note the exceptions mentioned in the
-subsection ``MMIO write barrier'').
+Section~\ref{sec:advsync:Device Operations}).

 \QuickQuiz{}
 	What effect does the following sequence have on the
-- 
1.9.1

Re: [PATCH 4/6] advsync: fix wrong code example

[Yokosawa Akira]

Sorry, I missed cc: to the list. Reposting...

-- 
Hi,

2016-04-02 9:28 GMT+09:00 SeongJae Park <sj38.park@gmail.com>:
> The code means `Y = *(A + 4)` but it is written as `Y = *A`. This commit
> fixes the typo.
>
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
> ---
>  advsync/memorybarriers.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index ee9312d..b1f49d3 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
>  \begin{minipage}[t]{\columnwidth}
>  \scriptsize
>  \begin{verbatim}
> -*A = X; Y = *A;
> +*A = X; Y = *(A + 4);

I think

+ *A = X; *(A + 4) = Y;

is what meets the possible combination given below.

STORE *A = X; STORE *(A + 4) = Y;
STORE *(A + 4) = Y; STORE *A = X;
STORE {*A, *(A + 4) } = {X, Y};

Regards,


--
Akira Yokosawa <akiysw@gmail.com>


>  \end{verbatim}
>  \end{minipage}
>  \vspace{5pt}
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe perfbook" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] advsync: fix wrong code example

[SeongJae Park]

Hi,

On Sat, 2 Apr 2016, Yokosawa Akira wrote:

> Sorry, I missed cc: to the list. Reposting...
>
> -- 
> Hi,
>
> 2016-04-02 9:28 GMT+09:00 SeongJae Park <sj38.park@gmail.com>:
>> The code means `Y = *(A + 4)` but it is written as `Y = *A`. This commit
>> fixes the typo.
>>
>> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
>> ---
>>  advsync/memorybarriers.tex | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
>> index ee9312d..b1f49d3 100644
>> --- a/advsync/memorybarriers.tex
>> +++ b/advsync/memorybarriers.tex
>> @@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
>>  \begin{minipage}[t]{\columnwidth}
>>  \scriptsize
>>  \begin{verbatim}
>> -*A = X; Y = *A;
>> +*A = X; Y = *(A + 4);
>
> I think
>
> + *A = X; *(A + 4) = Y;
>
> is what meets the possible combination given below.
>
> STORE *A = X; STORE *(A + 4) = Y;
> STORE *(A + 4) = Y; STORE *A = X;
> STORE {*A, *(A + 4) } = {X, Y};

Oops, you're right.  Thank you for let me know.  I will upload modified
version patch soon.


Thanks,
SeongJae Park

>
> Regards,
>
>
> --
> Akira Yokosawa <akiysw@gmail.com>
>
>
>>  \end{verbatim}
>>  \end{minipage}
>>  \vspace{5pt}
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe perfbook" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[PATCH] advsync: fix wrong code example

[SeongJae Park]

The code means `*(A + 4) = Y` but it is written as `Y = *A`. This commit
fixes the typo.

Suggested-by: Akira Yokosawa <akiysw@gmail.com>
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/memorybarriers.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index ee9312d..8e9c876 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
 \begin{minipage}[t]{\columnwidth}
 \scriptsize
 \begin{verbatim}
-*A = X; Y = *A;
+*A = X; *(A + 4) = Y;
 \end{verbatim}
 \end{minipage}
 \vspace{5pt}
-- 
1.9.1

Re: [PATCH 4/6] advsync: fix wrong code example

[Yokosawa Akira]

If you would like, I don't mind you adding

Suggested-by: Akira Yokosawa <akiysw@gmail.com>

to the commit log.

-- 
 Akira Yokosawa <akiysw@gmail.com>

2016-04-02 11:52 GMT+09:00 SeongJae Park <sj38.park@gmail.com>:
> Hi,
>
>
> On Sat, 2 Apr 2016, Yokosawa Akira wrote:
>
>> Sorry, I missed cc: to the list. Reposting...
>>
>> --
>> Hi,
>>
>> 2016-04-02 9:28 GMT+09:00 SeongJae Park <sj38.park@gmail.com>:
>>>
>>> The code means `Y = *(A + 4)` but it is written as `Y = *A`. This commit
>>> fixes the typo.
>>>
>>> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
>>> ---
>>>  advsync/memorybarriers.tex | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
>>> index ee9312d..b1f49d3 100644
>>> --- a/advsync/memorybarriers.tex
>>> +++ b/advsync/memorybarriers.tex
>>> @@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
>>>  \begin{minipage}[t]{\columnwidth}
>>>  \scriptsize
>>>  \begin{verbatim}
>>> -*A = X; Y = *A;
>>> +*A = X; Y = *(A + 4);
>>
>>
>> I think
>>
>> + *A = X; *(A + 4) = Y;
>>
>> is what meets the possible combination given below.
>>
>> STORE *A = X; STORE *(A + 4) = Y;
>> STORE *(A + 4) = Y; STORE *A = X;
>> STORE {*A, *(A + 4) } = {X, Y};
>
>
> Oops, you're right.  Thank you for let me know.  I will upload modified
> version patch soon.
>
>
> Thanks,
> SeongJae Park
>
>
>>
>> Regards,
>>
>>
>> --
>> Akira Yokosawa <akiysw@gmail.com>
>>
>>
>>>  \end{verbatim}
>>>  \end{minipage}
>>>  \vspace{5pt}
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe perfbook" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>

Re: [PATCH] advsync: fix wrong code example

[Yokosawa Akira]

Oh, You have already added the tag.
Thanks!

2016-04-02 12:03 GMT+09:00 SeongJae Park <sj38.park@gmail.com>:
> The code means `*(A + 4) = Y` but it is written as `Y = *A`. This commit
> fixes the typo.
>
> Suggested-by: Akira Yokosawa <akiysw@gmail.com>
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
> ---
>  advsync/memorybarriers.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index ee9312d..8e9c876 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
>  \begin{minipage}[t]{\columnwidth}
>  \scriptsize
>  \begin{verbatim}
> -*A = X; Y = *A;
> +*A = X; *(A + 4) = Y;
>  \end{verbatim}
>  \end{minipage}
>  \vspace{5pt}
> --
> 1.9.1
>

Re: [PATCH] advsync: fix wrong code example

[SeongJae Park]

On Sat, Apr 2, 2016 at 12:09 PM, Yokosawa Akira <akiyks@gmail.com> wrote:
> Oh, You have already added the tag.

Yes, I think you deserve it, of course. :)


Thanks,
SeongJae Park

> Thanks!
>
> 2016-04-02 12:03 GMT+09:00 SeongJae Park <sj38.park@gmail.com>:
>> The code means `*(A + 4) = Y` but it is written as `Y = *A`. This commit
>> fixes the typo.
>>
>> Suggested-by: Akira Yokosawa <akiysw@gmail.com>
>> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
>> ---
>>  advsync/memorybarriers.tex | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
>> index ee9312d..8e9c876 100644
>> --- a/advsync/memorybarriers.tex
>> +++ b/advsync/memorybarriers.tex
>> @@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
>>  \begin{minipage}[t]{\columnwidth}
>>  \scriptsize
>>  \begin{verbatim}
>> -*A = X; Y = *A;
>> +*A = X; *(A + 4) = Y;
>>  \end{verbatim}
>>  \end{minipage}
>>  \vspace{5pt}
>> --
>> 1.9.1
>>

Re: [PATCH 3/6] advsync: use latex reference feature consistently

[Paul E. McKenney]

On Sat, Apr 02, 2016 at 09:28:28AM +0900, SeongJae Park wrote:
> References to other sections in `Advanced Synchronization` chapter use
> latex reference feature and section name direct citation inconsistently.
> Because most other parts are using latex reference feature and it is
> easier for document maintainance, it would be better to use latex
> reference feature only.  For the reason, this commit enforces latex
> reference feature to the references.
> 
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>

One issue below, please fix and resubmit.

> ---
>  advsync/memorybarriers.tex | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index 15de36a..ee9312d 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -1454,7 +1454,8 @@ memory system as time progresses.  All stores before a write barrier will
>  occur in the sequence \emph{before} all the stores after the write barrier.
> 
>  $\dagger$ Note that write barriers should normally be paired with read
> -or data dependency barriers; see the ``SMP barrier pairing'' subsection.
> +or data dependency barriers; see the
> +Section~\ref{sec:advsync:SMP Barrier Pairing}.
> 
>  \paragraph{Data Dependency Barriers}
> 
> @@ -1479,19 +1480,19 @@ time the barrier completes, the effects of all the stores prior to that
>  touched by the load will be perceptible to any loads issued after the data
>  dependency barrier.
> 
> -See the ``Examples of memory barrier sequences'' subsection for diagrams
> -showing the ordering constraints.
> +See the Section~\ref{sec:advsync:Examples of Memory Barrier Pairings} for
> +diagrams showing the ordering constraints.
> 
>  $\dagger$ Note that the first load really has to have a
>  \emph{data} dependency and
>  not a control dependency.  If the address for the second load is dependent
>  on the first load, but the dependency is through a conditional rather than
>  actually loading the address itself, then it's a \emph{control} dependency and
> -a full read barrier or better is required.  See the ``Control dependencies''
> -subsection for more information.
> +a full read barrier or better is required.  See the
> +Section~\ref{sec:advsync:Control Dependencies} for more information.
> 
>  $\dagger$ Note that data dependency barriers should normally be paired with
> -write barriers; see the ``SMP barrier pairing'' subsection.
> +write barriers; see the Section~\ref{sec:advsync:SMP Barrier Pairign}.

The above gets me a LaTeX error, could you please fix and resubmit?
It is good practice to verify that it builds beforehand.  ;-)

							Thanx, Paul

> 
>  \paragraph{Read Memory Barriers}
> 
> @@ -1593,7 +1594,8 @@ of the confines of a given architecture:
>  \item	There is no guarantee that a CPU will see the correct order
>  	of effects from a second CPU's accesses, even \emph{if} the second CPU
>  	uses a memory barrier, unless the first CPU \emph{also} uses a matching
> -	memory barrier (see the subsection on ``SMP Barrier Pairing'').
> +	memory barrier (see the
> +	Section~\ref{sec:advsync:SMP Barrier Pairing}).
>  \item	There is no guarantee that some intervening piece of off-the-CPU
>  	hardware\footnote{
>  		This is of concern primarily in operating-system kernels.
> -- 
> 1.9.1
> 

Re: [PATCH 2/6] advsync: fix latex syntax related typos

[Paul E. McKenney]

On Sat, Apr 02, 2016 at 09:28:27AM +0900, SeongJae Park wrote:
> This commit fixes typos related with latex.  The typos include:
> unnecessarily doubly inserted commas, missed tildes, missed dots,
> wrongly located dot and question mark, unwrapped citation.
> 
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>

Some good ones, and some that I cannot accept.  Could you please resubmit
as noted below?

							Thanx, Paul

> ---
>  advsync/advsync.tex        |  4 ++--
>  advsync/memorybarriers.tex | 22 +++++++++++-----------
>  2 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/advsync/advsync.tex b/advsync/advsync.tex
> index 118dc74..12bacbf 100644
> --- a/advsync/advsync.tex
> +++ b/advsync/advsync.tex
> @@ -78,14 +78,14 @@ basis of real-time programming:
>  \begin{enumerate}
>  \item	Real-time forward-progress guarantees usually have some
>  	definite time associated with them, for example,
> -	``scheduling latency must be less than 100 microseconds.''
> +	``scheduling latency must be less than 100 microseconds.''.

We should have be period either before or after the quates, not both.
The exception would be if the quotes contained a computer command that
ended with a period.

>  	In contrast, the most popular forms of NBS only guarantees
>  	that progress will be made in finite time, with no definite
>  	bound.
>  \item	Real-time forward-progress guarantees are sometimes
>  	probabilistic, as in the soft-real-time guarantee that
>  	``at least 99.9\% of the time, scheduling latency must
> -	be less than 100 microseconds.''
> +	be less than 100 microseconds.''.

Ditto.

>  	In contrast, NBS's forward-progress
>  	guarantees have traditionally been unconditional.
>  \item	Real-time forward-progress guarantees are often conditioned on
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index c668f3c..15de36a 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -37,7 +37,7 @@ appears to guarantee that the assertion never fires.
>  After all, if \co{r1 != 1}, we might hope that Thread~1's load from \co{y}
>  must have happened before Thread~2's store to \co{y}, which might raise
>  further hopes that Thread~2's load from \co{x} must happen after
> -Thread 1's store to \co{x}, so that \co{r2 == 1}, as required by the
> +Thread~1's store to \co{x}, so that \co{r2 == 1}, as required by the

This is fine.

>  assertion.
>  The example is symmetric, so similar hopeful reasoning might lead
>  us to hope that \co{r2 != 1} guarantees that \co{r1 == 1}.
> @@ -295,7 +295,7 @@ over a 532-nanosecond time period, as shown in
>  Figure~\ref{fig:advsync:A Variable With Multiple Simultaneous Values}.
>  This data was collected on 1.5GHz POWER5 system with 8 cores, each containing
>  a pair of hardware threads.
> -CPUs~1, 2, 3, and 4 recorded the values, while CPU 0 controlled the test.
> +CPUs~1, 2, 3, and 4 recorded the values, while CPU~0 controlled the test.

This is a good change, but should have "and~4" as well.

>  The timebase counter period was about 5.32ns, sufficiently fine-grained
>  to allow observations of intermediate cache states.
> 
> @@ -320,7 +320,7 @@ CPU~4 believes that the value is ``4'' for almost 500ns.
> 
>  \QuickQuiz{}
>  	How could CPUs possibly have different views of the
> -	value of a single variable \emph{at the same time?}
> +	value of a single variable \emph{at the same time}?

It looks better if the question mark has the same itailics state
as the word immediately preceding it, so this should remain as is.

>  \QuickQuizAnswer{
>  	Many CPUs have write buffers that record the values of
>  	recent writes, which are applied once the corresponding
> @@ -459,8 +459,8 @@ For example, in the following set of operations, CPU~1's access to
>  A does not unconditionally precede its access to B from the viewpoint
>  of an external logic analyzer
>  \IfInBook{(see Appendix~\ref{chp:app:whymb:Why Memory Barriers?}
> -	  for examples).
> -	 }
> +	  for examples)
> +	 }.

Aren't the "then" and "else" clauses supposed to be right next to each
other?  I don't believe this change works.

>  	 {(the system is only to act \emph{as if} the accesses
>  	  are in order; it is not necessarily required to actually
>  	  force them to be in order).}
> @@ -1037,10 +1037,10 @@ a few simple rules:
>  		for example, if a given CPU never loaded or stored
>  		the shared variable, then it can have no opinion about
>  		that variable's value.}
> -\item	If one CPU does ordered stores to variables A and B,\footnote{
> +\item	If one CPU does ordered stores to variables A and B\footnote{
>  		For example, by executing the store to A, a
>  		memory barrier, and then the store to B.},
> -	and if a second CPU does ordered loads from B and A,\footnote{
> +	and if a second CPU does ordered loads from B and A\footnote{

The footnote should be after the comma, otherwise the spacing looks
strange.  (Might be different in Korean, of course.)

>  		For example, by executing the load from B, a
>  		memory barrier, and then the load from A.},
>  	then if the second CPU's load from B gives the value stored
> @@ -1903,9 +1903,9 @@ In the above example, CPU~2 perceives that \co{B} is 7,
>  despite the load of \co{*C}
>  (which would be \co{B}) coming after the \co{LOAD} of \co{C}.
> 
> -If, however, a data dependency barrier were to be placed between the load of C
> -and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial values of
> -{\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:
> +If, however, a data dependency barrier were to be placed between the load of
> +\co{C} and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial
> +values of {\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:

This one looks good.

>  \vspace{5pt}
>  \begin{minipage}[t]{\columnwidth}
> @@ -2002,7 +2002,7 @@ Figure~\ref{fig:advsync:Read Barrier Supplied}.
>  \end{figure*}
> 
>  To illustrate this more completely, consider what could happen if the code
> -contained a load of A either side of the read barrier, once again
> +contained a load of \co{A} either side of the read barrier, once again

This one does too.

>  with the same initial values of
>  {\tt \{A = 0, B = 9\}}:
> 
> -- 
> 1.9.1
> 

Re: [PATCH 1/6] advsync: Fix trivial typos

[Paul E. McKenney]

On Sat, Apr 02, 2016 at 09:28:26AM +0900, SeongJae Park wrote:
> This commit fixes trivial typos under `advsync/` directory.
> 
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>

Queued, thank you!

							Thanx, Paul

> ---
>  advsync/advsync.tex        | 4 ++--
>  advsync/memorybarriers.tex | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/advsync/advsync.tex b/advsync/advsync.tex
> index 7250e96..118dc74 100644
> --- a/advsync/advsync.tex
> +++ b/advsync/advsync.tex
> @@ -30,7 +30,7 @@ gives a brief overview of non-blocking synchronization.
> 
>  Although locking is the workhorse of parallelism in production, in
>  many situations performance, scalability, and real-time response can
> -all be greatly improved though use of lockless techniques.
> +all be greatly improved through use of lockless techniques.
>  A particularly impressive example of such a lockless technique are
>  the statistical counters describe in
>  Section~\ref{sec:count:Statistical Counters},
> @@ -45,7 +45,7 @@ Other examples we have covered include:
>  	Section~\ref{sec:SMPdesign:Resource Allocator Caches}.
>  \item	The maze solver in Section~\ref{sec:SMPdesign:Beyond Partitioning}.
>  \item	The data-ownership techniques described in
> -	Section~\ref{chp:Data Ownership}.
> +	Chapter~\ref{chp:Data Ownership}.
>  \item	The reference-counting and RCU techinques described in
>  	Chapter~\ref{chp:Deferred Processing}.
>  \item	The lookup code paths described in Chapter~\ref{chp:Data Structures}.
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index 99e074d..c668f3c 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -759,7 +759,7 @@ these combinations in order to fully understand how this works.
>  	it is not possible for one of the loads to see the
>  	results of the other load.
>  	However, if we know that CPU~2's load from B returned a
> -	newer value than CPU~1's load from B, the we also know
> +	newer value than CPU~1's load from B, then we also know
>  	that CPU~2's load from A returned either the same value
>  	as CPU~1's load from A or some later value.
> 
> @@ -1047,7 +1047,7 @@ a few simple rules:
>  	by the first CPU, then the second CPU's load from A must
>  	give the value stored by the first CPU.
>  \item	If one CPU does a load from A ordered before a store to B,
> -	and if a second CPU does a load from B ordered before a store from A,
> +	and if a second CPU does a load from B ordered before a store to A,
>  	and if the second CPU's load from B gives the value stored by
>  	the first CPU, then the first CPU's load from A must \emph{not}
>  	give the value stored by the second CPU.
> -- 
> 1.9.1
> 

Re: [PATCH 5/6] advsync: Fix critical section bleed-in description

[Paul E. McKenney]

On Sat, Apr 02, 2016 at 09:28:30AM +0900, SeongJae Park wrote:
> A sentence in `Locking Examples` section says both LOCK and UNLOCK
> allows preceding operations `bleed in` to the critical section.
> However, it's wrong description.  LOCK allows only preceding operations
> and UNLOCK allows only following operations to bleed in.  Looks like the
> wrong description made by just a trivial mistake.  This commit fixes the
> sentence to have correct description.
> 
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>

Queued, thank you!

							Thanx, Paul

> ---
>  advsync/memorybarriers.tex | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index b1f49d3..1fe0953 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -2232,8 +2232,9 @@ might well execute in the following order:
>  \end{minipage}
>  \vspace{5pt}
> 
> -Again, always remember that both LOCK and UNLOCK are permitted to let
> -preceding operations ``bleed in'' to the critical section.
> +Again, always remember that LOCK and UNLOCK are permitted to let preceding
> +operations and following operations ``bleed in'' to the critical section
> +respectively.
> 
>  \QuickQuiz{}
>  	What sequence of LOCK-UNLOCK operations \emph{would}
> -- 
> 1.9.1
> 

Re: [PATCH 6/6] advsync: Fix wrong reference to section ``MMIO write barrier''

[Paul E. McKenney]

On Sat, Apr 02, 2016 at 09:28:31AM +0900, SeongJae Park wrote:
> A sentence references ``MMIO write barrier'' subsection though the
> section does not exists.  Unfortunately, there is no section for MMIO
> write barrier though appendix ``Why Memory Barriers?'' says about
> mmiowb() subtly.  For the purpose of the sentence, it could be
> alternated with reference to ``Device operations'' subsection because it
> describes about the exceptional case.  For the reason, this commit
> updates it to the reference to ``Device Operations'' subsection.
> 
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>

Queued, thank you!

							Thanx, Paul

> ---
>  advsync/memorybarriers.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index 1fe0953..b511f51 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -1559,7 +1559,7 @@ other strictly in the order specified.
> 
>  The use of LOCK and UNLOCK operations generally precludes the need for
>  other sorts of memory barrier (but note the exceptions mentioned in the
> -subsection ``MMIO write barrier'').
> +Section~\ref{sec:advsync:Device Operations}).
> 
>  \QuickQuiz{}
>  	What effect does the following sequence have on the
> -- 
> 1.9.1
> 

Re: [PATCH] advsync: Fix wrong code example

[Paul E. McKenney]

On Sat, Apr 02, 2016 at 12:03:56PM +0900, SeongJae Park wrote:
> The code means `*(A + 4) = Y` but it is written as `Y = *A`. This commit
> fixes the typo.
> 
> Suggested-by: Akira Yokosawa <akiysw@gmail.com>
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>

Queued, thank you!

							Thanx, Paul

> ---
>  advsync/memorybarriers.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index ee9312d..8e9c876 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -1364,7 +1364,7 @@ Y = LOAD *(A + 4); X = LOAD *A;
>  \begin{minipage}[t]{\columnwidth}
>  \scriptsize
>  \begin{verbatim}
> -*A = X; Y = *A;
> +*A = X; *(A + 4) = Y;
>  \end{verbatim}
>  \end{minipage}
>  \vspace{5pt}
> -- 
> 1.9.1
> 

Re: [PATCH 2/6] advsync: fix latex syntax related typos

[SeongJae Park]

Hello,

On Sun, 3 Apr 2016, Paul E. McKenney wrote:

> On Sat, Apr 02, 2016 at 09:28:27AM +0900, SeongJae Park wrote:
>> This commit fixes typos related with latex.  The typos include:
>> unnecessarily doubly inserted commas, missed tildes, missed dots,
>> wrongly located dot and question mark, unwrapped citation.
>>
>> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
>
> Some good ones, and some that I cannot accept.  Could you please resubmit
> as noted below?

Thanks for your opinion.  I will do resubmit soon.

>
> 							Thanx, Paul
>
>> ---
>>  advsync/advsync.tex        |  4 ++--
>>  advsync/memorybarriers.tex | 22 +++++++++++-----------
>>  2 files changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/advsync/advsync.tex b/advsync/advsync.tex
>> index 118dc74..12bacbf 100644
>> --- a/advsync/advsync.tex
>> +++ b/advsync/advsync.tex
>> @@ -78,14 +78,14 @@ basis of real-time programming:
>>  \begin{enumerate}
>>  \item	Real-time forward-progress guarantees usually have some
>>  	definite time associated with them, for example,
>> -	``scheduling latency must be less than 100 microseconds.''
>> +	``scheduling latency must be less than 100 microseconds.''.
>
> We should have be period either before or after the quates, not both.
> The exception would be if the quotes contained a computer command that
> ended with a period.

Okay.

>
>>  	In contrast, the most popular forms of NBS only guarantees
>>  	that progress will be made in finite time, with no definite
>>  	bound.
>>  \item	Real-time forward-progress guarantees are sometimes
>>  	probabilistic, as in the soft-real-time guarantee that
>>  	``at least 99.9\% of the time, scheduling latency must
>> -	be less than 100 microseconds.''
>> +	be less than 100 microseconds.''.
>
> Ditto.

Okay.

>
>>  	In contrast, NBS's forward-progress
>>  	guarantees have traditionally been unconditional.
>>  \item	Real-time forward-progress guarantees are often conditioned on
>> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
>> index c668f3c..15de36a 100644
>> --- a/advsync/memorybarriers.tex
>> +++ b/advsync/memorybarriers.tex
>> @@ -37,7 +37,7 @@ appears to guarantee that the assertion never fires.
>>  After all, if \co{r1 != 1}, we might hope that Thread~1's load from \co{y}
>>  must have happened before Thread~2's store to \co{y}, which might raise
>>  further hopes that Thread~2's load from \co{x} must happen after
>> -Thread 1's store to \co{x}, so that \co{r2 == 1}, as required by the
>> +Thread~1's store to \co{x}, so that \co{r2 == 1}, as required by the
>
> This is fine.
>
>>  assertion.
>>  The example is symmetric, so similar hopeful reasoning might lead
>>  us to hope that \co{r2 != 1} guarantees that \co{r1 == 1}.
>> @@ -295,7 +295,7 @@ over a 532-nanosecond time period, as shown in
>>  Figure~\ref{fig:advsync:A Variable With Multiple Simultaneous Values}.
>>  This data was collected on 1.5GHz POWER5 system with 8 cores, each containing
>>  a pair of hardware threads.
>> -CPUs~1, 2, 3, and 4 recorded the values, while CPU 0 controlled the test.
>> +CPUs~1, 2, 3, and 4 recorded the values, while CPU~0 controlled the test.
>
> This is a good change, but should have "and~4" as well.
>
>>  The timebase counter period was about 5.32ns, sufficiently fine-grained
>>  to allow observations of intermediate cache states.
>>
>> @@ -320,7 +320,7 @@ CPU~4 believes that the value is ``4'' for almost 500ns.
>>
>>  \QuickQuiz{}
>>  	How could CPUs possibly have different views of the
>> -	value of a single variable \emph{at the same time?}
>> +	value of a single variable \emph{at the same time}?
>
> It looks better if the question mark has the same itailics state
> as the word immediately preceding it, so this should remain as is.

Okay.

>
>>  \QuickQuizAnswer{
>>  	Many CPUs have write buffers that record the values of
>>  	recent writes, which are applied once the corresponding
>> @@ -459,8 +459,8 @@ For example, in the following set of operations, CPU~1's access to
>>  A does not unconditionally precede its access to B from the viewpoint
>>  of an external logic analyzer
>>  \IfInBook{(see Appendix~\ref{chp:app:whymb:Why Memory Barriers?}
>> -	  for examples).
>> -	 }
>> +	  for examples)
>> +	 }.
>
> Aren't the "then" and "else" clauses supposed to be right next to each
> other?  I don't believe this change works.

Ah, you're right.

>
>>  	 {(the system is only to act \emph{as if} the accesses
>>  	  are in order; it is not necessarily required to actually
>>  	  force them to be in order).}
>> @@ -1037,10 +1037,10 @@ a few simple rules:
>>  		for example, if a given CPU never loaded or stored
>>  		the shared variable, then it can have no opinion about
>>  		that variable's value.}
>> -\item	If one CPU does ordered stores to variables A and B,\footnote{
>> +\item	If one CPU does ordered stores to variables A and B\footnote{
>>  		For example, by executing the store to A, a
>>  		memory barrier, and then the store to B.},
>> -	and if a second CPU does ordered loads from B and A,\footnote{
>> +	and if a second CPU does ordered loads from B and A\footnote{
>
> The footnote should be after the comma, otherwise the spacing looks
> strange.  (Might be different in Korean, of course.)

Okay.


Thanks,
SeongJae Park

>
>>  		For example, by executing the load from B, a
>>  		memory barrier, and then the load from A.},
>>  	then if the second CPU's load from B gives the value stored
>> @@ -1903,9 +1903,9 @@ In the above example, CPU~2 perceives that \co{B} is 7,
>>  despite the load of \co{*C}
>>  (which would be \co{B}) coming after the \co{LOAD} of \co{C}.
>>
>> -If, however, a data dependency barrier were to be placed between the load of C
>> -and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial values of
>> -{\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:
>> +If, however, a data dependency barrier were to be placed between the load of
>> +\co{C} and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial
>> +values of {\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:
>
> This one looks good.
>
>>  \vspace{5pt}
>>  \begin{minipage}[t]{\columnwidth}
>> @@ -2002,7 +2002,7 @@ Figure~\ref{fig:advsync:Read Barrier Supplied}.
>>  \end{figure*}
>>
>>  To illustrate this more completely, consider what could happen if the code
>> -contained a load of A either side of the read barrier, once again
>> +contained a load of \co{A} either side of the read barrier, once again
>
> This one does too.
>
>>  with the same initial values of
>>  {\tt \{A = 0, B = 9\}}:
>>
>> --
>> 1.9.1
>>
>
>

[PATCH] advsync: fix latex syntax related typos

[SeongJae Park]

This commit fixes typos related with latex.  The typos include:
missed tildes, doubly inserted commas, and incinsistently formatted code
citations.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/memorybarriers.tex | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index c668f3c..47d910a 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -37,7 +37,7 @@ appears to guarantee that the assertion never fires.
 After all, if \co{r1 != 1}, we might hope that Thread~1's load from \co{y}
 must have happened before Thread~2's store to \co{y}, which might raise
 further hopes that Thread~2's load from \co{x} must happen after
-Thread 1's store to \co{x}, so that \co{r2 == 1}, as required by the
+Thread~1's store to \co{x}, so that \co{r2 == 1}, as required by the
 assertion.
 The example is symmetric, so similar hopeful reasoning might lead
 us to hope that \co{r2 != 1} guarantees that \co{r1 == 1}.
@@ -295,7 +295,7 @@ over a 532-nanosecond time period, as shown in
 Figure~\ref{fig:advsync:A Variable With Multiple Simultaneous Values}.
 This data was collected on 1.5GHz POWER5 system with 8 cores, each containing
 a pair of hardware threads.
-CPUs~1, 2, 3, and 4 recorded the values, while CPU 0 controlled the test.
+CPUs~1, 2, 3, and~4 recorded the values, while CPU~0 controlled the test.
 The timebase counter period was about 5.32ns, sufficiently fine-grained
 to allow observations of intermediate cache states.

@@ -1039,10 +1039,10 @@ a few simple rules:
 		that variable's value.}
 \item	If one CPU does ordered stores to variables A and B,\footnote{
 		For example, by executing the store to A, a
-		memory barrier, and then the store to B.},
+		memory barrier, and then the store to B.}
 	and if a second CPU does ordered loads from B and A,\footnote{
 		For example, by executing the load from B, a
-		memory barrier, and then the load from A.},
+		memory barrier, and then the load from A.}
 	then if the second CPU's load from B gives the value stored
 	by the first CPU, then the second CPU's load from A must
 	give the value stored by the first CPU.
@@ -1903,9 +1903,9 @@ In the above example, CPU~2 perceives that \co{B} is 7,
 despite the load of \co{*C}
 (which would be \co{B}) coming after the \co{LOAD} of \co{C}.

-If, however, a data dependency barrier were to be placed between the load of C
-and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial values of
-{\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:
+If, however, a data dependency barrier were to be placed between the load of
+\co{C} and the load of \co{*C} (i.e.: \co{B}) on CPU~2, again with initial
+values of {\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:

 \vspace{5pt}
 \begin{minipage}[t]{\columnwidth}
@@ -2002,7 +2002,7 @@ Figure~\ref{fig:advsync:Read Barrier Supplied}.
 \end{figure*}

 To illustrate this more completely, consider what could happen if the code
-contained a load of A either side of the read barrier, once again
+contained a load of \co{A} either side of the read barrier, once again
 with the same initial values of
 {\tt \{A = 0, B = 9\}}:

-- 
1.9.1

Re: [PATCH 3/6] advsync: use latex reference feature consistently

[SeongJae Park]

Hello,

On Sun, 3 Apr 2016, Paul E. McKenney wrote:

> On Sat, Apr 02, 2016 at 09:28:28AM +0900, SeongJae Park wrote:
>> References to other sections in `Advanced Synchronization` chapter use
>> latex reference feature and section name direct citation inconsistently.
>> Because most other parts are using latex reference feature and it is
>> easier for document maintainance, it would be better to use latex
>> reference feature only.  For the reason, this commit enforces latex
>> reference feature to the references.
>>
>> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
>
> One issue below, please fix and resubmit.

Sure.  I will resubmit in reply to this mail.

>
>> ---
>>  advsync/memorybarriers.tex | 16 +++++++++-------
>>  1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
>> index 15de36a..ee9312d 100644
>> --- a/advsync/memorybarriers.tex
>> +++ b/advsync/memorybarriers.tex
>> @@ -1454,7 +1454,8 @@ memory system as time progresses.  All stores before a write barrier will
>>  occur in the sequence \emph{before} all the stores after the write barrier.
>>
>>  $\dagger$ Note that write barriers should normally be paired with read
>> -or data dependency barriers; see the ``SMP barrier pairing'' subsection.
>> +or data dependency barriers; see the
>> +Section~\ref{sec:advsync:SMP Barrier Pairing}.
>>
>>  \paragraph{Data Dependency Barriers}
>>
>> @@ -1479,19 +1480,19 @@ time the barrier completes, the effects of all the stores prior to that
>>  touched by the load will be perceptible to any loads issued after the data
>>  dependency barrier.
>>
>> -See the ``Examples of memory barrier sequences'' subsection for diagrams
>> -showing the ordering constraints.
>> +See the Section~\ref{sec:advsync:Examples of Memory Barrier Pairings} for
>> +diagrams showing the ordering constraints.
>>
>>  $\dagger$ Note that the first load really has to have a
>>  \emph{data} dependency and
>>  not a control dependency.  If the address for the second load is dependent
>>  on the first load, but the dependency is through a conditional rather than
>>  actually loading the address itself, then it's a \emph{control} dependency and
>> -a full read barrier or better is required.  See the ``Control dependencies''
>> -subsection for more information.
>> +a full read barrier or better is required.  See the
>> +Section~\ref{sec:advsync:Control Dependencies} for more information.
>>
>>  $\dagger$ Note that data dependency barriers should normally be paired with
>> -write barriers; see the ``SMP barrier pairing'' subsection.
>> +write barriers; see the Section~\ref{sec:advsync:SMP Barrier Pairign}.
>
> The above gets me a LaTeX error, could you please fix and resubmit?
> It is good practice to verify that it builds beforehand.  ;-)

Oh, my fault... Sorry and thanks for your kind comment :)  I will fix it
and resubmit in reply to this mail as soon as possible.

>
> 							Thanx, Paul
>
>>
>>  \paragraph{Read Memory Barriers}
>>
>> @@ -1593,7 +1594,8 @@ of the confines of a given architecture:
>>  \item	There is no guarantee that a CPU will see the correct order
>>  	of effects from a second CPU's accesses, even \emph{if} the second CPU
>>  	uses a memory barrier, unless the first CPU \emph{also} uses a matching
>> -	memory barrier (see the subsection on ``SMP Barrier Pairing'').
>> +	memory barrier (see the
>> +	Section~\ref{sec:advsync:SMP Barrier Pairing}).
>>  \item	There is no guarantee that some intervening piece of off-the-CPU
>>  	hardware\footnote{
>>  		This is of concern primarily in operating-system kernels.
>> --
>> 1.9.1
>>
>
>

[PATCH] advsync: use latex reference feature consistently

[SeongJae Park]

References to other sections in `Advanced Synchronization` chapter use
latex reference feature and section name direct citation inconsistently.
Because most other parts are using latex reference feature and it is
easier for document maintainance, it would be better to use latex
reference feature only.  For the reason, this commit enforces latex
reference feature to the references.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 advsync/memorybarriers.tex | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 47d910a..3f5c293 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -1454,7 +1454,8 @@ memory system as time progresses.  All stores before a write barrier will
 occur in the sequence \emph{before} all the stores after the write barrier.

 $\dagger$ Note that write barriers should normally be paired with read
-or data dependency barriers; see the ``SMP barrier pairing'' subsection.
+or data dependency barriers; see the
+Section~\ref{sec:advsync:SMP Barrier Pairing}.

 \paragraph{Data Dependency Barriers}

@@ -1479,19 +1480,19 @@ time the barrier completes, the effects of all the stores prior to that
 touched by the load will be perceptible to any loads issued after the data
 dependency barrier.

-See the ``Examples of memory barrier sequences'' subsection for diagrams
-showing the ordering constraints.
+See the Section~\ref{sec:advsync:Examples of Memory Barrier Pairings} for
+diagrams showing the ordering constraints.

 $\dagger$ Note that the first load really has to have a
 \emph{data} dependency and
 not a control dependency.  If the address for the second load is dependent
 on the first load, but the dependency is through a conditional rather than
 actually loading the address itself, then it's a \emph{control} dependency and
-a full read barrier or better is required.  See the ``Control dependencies''
-subsection for more information.
+a full read barrier or better is required.  See the
+Section~\ref{sec:advsync:Control Dependencies} for more information.

 $\dagger$ Note that data dependency barriers should normally be paired with
-write barriers; see the ``SMP barrier pairing'' subsection.
+write barriers; see the Section~\ref{sec:advsync:SMP Barrier Pairing}.

 \paragraph{Read Memory Barriers}

@@ -1593,7 +1594,8 @@ of the confines of a given architecture:
 \item	There is no guarantee that a CPU will see the correct order
 	of effects from a second CPU's accesses, even \emph{if} the second CPU
 	uses a memory barrier, unless the first CPU \emph{also} uses a matching
-	memory barrier (see the subsection on ``SMP Barrier Pairing'').
+	memory barrier (see the
+	Section~\ref{sec:advsync:SMP Barrier Pairing}).
 \item	There is no guarantee that some intervening piece of off-the-CPU
 	hardware\footnote{
 		This is of concern primarily in operating-system kernels.
-- 
1.9.1

Re: [PATCH] advsync: use latex reference feature consistently

[Paul E. McKenney]

On Mon, Apr 04, 2016 at 07:33:41AM +0900, SeongJae Park wrote:
> References to other sections in `Advanced Synchronization` chapter use
> latex reference feature and section name direct citation inconsistently.
> Because most other parts are using latex reference feature and it is
> easier for document maintainance, it would be better to use latex
> reference feature only.  For the reason, this commit enforces latex
> reference feature to the references.
> 
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>

Queued both, thank you!

							Thanx, Paul

> ---
>  advsync/memorybarriers.tex | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index 47d910a..3f5c293 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -1454,7 +1454,8 @@ memory system as time progresses.  All stores before a write barrier will
>  occur in the sequence \emph{before} all the stores after the write barrier.
> 
>  $\dagger$ Note that write barriers should normally be paired with read
> -or data dependency barriers; see the ``SMP barrier pairing'' subsection.
> +or data dependency barriers; see the
> +Section~\ref{sec:advsync:SMP Barrier Pairing}.
> 
>  \paragraph{Data Dependency Barriers}
> 
> @@ -1479,19 +1480,19 @@ time the barrier completes, the effects of all the stores prior to that
>  touched by the load will be perceptible to any loads issued after the data
>  dependency barrier.
> 
> -See the ``Examples of memory barrier sequences'' subsection for diagrams
> -showing the ordering constraints.
> +See the Section~\ref{sec:advsync:Examples of Memory Barrier Pairings} for
> +diagrams showing the ordering constraints.
> 
>  $\dagger$ Note that the first load really has to have a
>  \emph{data} dependency and
>  not a control dependency.  If the address for the second load is dependent
>  on the first load, but the dependency is through a conditional rather than
>  actually loading the address itself, then it's a \emph{control} dependency and
> -a full read barrier or better is required.  See the ``Control dependencies''
> -subsection for more information.
> +a full read barrier or better is required.  See the
> +Section~\ref{sec:advsync:Control Dependencies} for more information.
> 
>  $\dagger$ Note that data dependency barriers should normally be paired with
> -write barriers; see the ``SMP barrier pairing'' subsection.
> +write barriers; see the Section~\ref{sec:advsync:SMP Barrier Pairing}.
> 
>  \paragraph{Read Memory Barriers}
> 
> @@ -1593,7 +1594,8 @@ of the confines of a given architecture:
>  \item	There is no guarantee that a CPU will see the correct order
>  	of effects from a second CPU's accesses, even \emph{if} the second CPU
>  	uses a memory barrier, unless the first CPU \emph{also} uses a matching
> -	memory barrier (see the subsection on ``SMP Barrier Pairing'').
> +	memory barrier (see the
> +	Section~\ref{sec:advsync:SMP Barrier Pairing}).
>  \item	There is no guarantee that some intervening piece of off-the-CPU
>  	hardware\footnote{
>  		This is of concern primarily in operating-system kernels.
> -- 
> 1.9.1
>