Discussions of the Parallel Programming book
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: SeongJae Park <sj38.park@gmail.com>
Cc: dhowells@redhat.com, perfbook@vger.kernel.org
Subject: Re: [PATCH 2/6] advsync: fix latex syntax related typos
Date: Sun, 3 Apr 2016 06:52:11 -0700	[thread overview]
Message-ID: <20160403135211.GM3663@linux.vnet.ibm.com> (raw)
In-Reply-To: <1459556911-11538-3-git-send-email-sj38.park@gmail.com>

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
> 


  reply	other threads:[~2016-04-03 13:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-02  0:28 [PATCH 0/6] fix trivial problems in advanced synchronization chapter SeongJae Park
2016-04-02  0:28 ` [PATCH 1/6] advsync: fix trivial typos SeongJae Park
2016-04-03 13:56   ` [PATCH 1/6] advsync: Fix " Paul E. McKenney
2016-04-02  0:28 ` [PATCH 2/6] advsync: fix latex syntax related typos SeongJae Park
2016-04-03 13:52   ` Paul E. McKenney [this message]
2016-04-03 22:10     ` SeongJae Park
2016-04-03 22:25       ` [PATCH] " SeongJae Park
2016-04-02  0:28 ` [PATCH 3/6] advsync: use latex reference feature consistently SeongJae Park
2016-04-03 13:37   ` Paul E. McKenney
2016-04-03 22:30     ` SeongJae Park
2016-04-03 22:33       ` [PATCH] " SeongJae Park
2016-04-07 21:05         ` Paul E. McKenney
2016-04-02  0:28 ` [PATCH 4/6] advsync: fix wrong code example SeongJae Park
2016-04-02  2:39   ` Yokosawa Akira
2016-04-02  2:52     ` SeongJae Park
2016-04-02  3:03       ` [PATCH] " SeongJae Park
2016-04-02  3:09         ` Yokosawa Akira
2016-04-02  3:12           ` SeongJae Park
2016-04-03 13:57         ` [PATCH] advsync: Fix " Paul E. McKenney
2016-04-02  3:06       ` [PATCH 4/6] advsync: fix " Yokosawa Akira
2016-04-02  0:28 ` [PATCH 5/6] advsync: fix critical section bleed-in description SeongJae Park
2016-04-03 13:57   ` [PATCH 5/6] advsync: Fix " Paul E. McKenney
2016-04-02  0:28 ` [PATCH 6/6] advsync: fix wrong reference to section ``MMIO write barrier'' SeongJae Park
2016-04-03 13:57   ` [PATCH 6/6] advsync: Fix " Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160403135211.GM3663@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=perfbook@vger.kernel.org \
    --cc=sj38.park@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox