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
>
next prev parent 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