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 3/6] advsync: use latex reference feature consistently
Date: Sun, 3 Apr 2016 06:37:32 -0700	[thread overview]
Message-ID: <20160403133732.GJ3663@linux.vnet.ibm.com> (raw)
In-Reply-To: <1459556911-11538-4-git-send-email-sj38.park@gmail.com>

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
> 


  reply	other threads:[~2016-04-03 13:37 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
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 [this message]
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=20160403133732.GJ3663@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