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@xxxxxxxxx>
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
>
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
