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

[SeongJae Park <sj38.park@gmail.com>]

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
>>
>
>