[PATCH] advsync/mb: fix wrong value of B in data dep example

[PATCH] advsync/mb: fix wrong value of B in data dep example

[Emilio G. Cota]

Signed-off-by: Emilio G. Cota <cota@braap.org>
---
 advsync/memorybarriers.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index e512785..cc11323 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -1667,65 +1667,65 @@ To deal with this, a data dependency barrier must be inserted between the
 address load and the data load (again with initial values of
 {\tt \{A = 1, B = 2, C = 3, P = \&A, Q = \&C\}}):

 \vspace{5pt}
 \begin{minipage}[t]{\columnwidth}
 \tt
 \scriptsize
 \begin{tabular}{l|p{1.5in}}
 	CPU 1 &		CPU 2 \\
 	\hline
 	B = 4; & \\
 	<write barrier> & \\
 	P = \&B; &	\\
 		&	Q = P; \\
 		&	<data dependency barrier> \\
 		&	D = *Q; \\
 \end{tabular}
 \end{minipage}
 \vspace{5pt}

 This enforces the occurrence of one of the two implications, and prevents the
 third possibility from arising.

 Note that this extremely counterintuitive situation arises most easily on
 machines with split caches, so that, for example, one cache bank processes
 even-numbered cache lines and the other bank processes odd-numbered cache
 lines.
 The pointer \co{P} might be stored in an odd-numbered cache line, and the
 variable \co{B} might be stored in an even-numbered cache line.  Then, if the
 even-numbered bank of the reading CPU's cache is extremely busy while the
 odd-numbered bank is idle, one can see the new value of the
 pointer \co{P} (which is \co{&B}),
-but the old value of the variable \co{B} (which is 1).
+but the old value of the variable \co{B} (which is 2).

 Another example of where data dependency barriers might by required is where a
 number is read from memory and then used to calculate the index for an array
 access with initial values
 {\tt \{M[0] = 1, M[1] = 2, M[3] = 3, P = 0, Q = 3\}}:

 \vspace{5pt}
 \begin{minipage}[t]{\columnwidth}
 \tt
 \scriptsize
 \begin{tabular}{l|p{1.5in}}
 	CPU 1 &		CPU 2 \\
 	\hline
 	M[1] = 4; & \\
 	<write barrier> & \\
 	P = 1;	&	\\
 		&	Q = P; \\
 		&	<data dependency barrier> \\
 		&	D = M[Q]; \\
 \end{tabular}
 \end{minipage}
 \vspace{5pt}

 The data dependency barrier is very important to the Linux kernel's
 RCU system, for example,
 see \co{rcu_dereference()} in \url{include/linux/rcupdate.h}.
 This permits the current
 target of an RCU'd pointer to be replaced with a new modified target, without
 the replacement target appearing to be incompletely initialised.

 See also
 Section~\ref{sec:advsync:Cache Coherency}
-- 
1.9.1

Re: [PATCH] advsync/mb: fix wrong value of B in data dep example

[Paul E. McKenney]

On Tue, Mar 17, 2015 at 08:30:22PM -0400, Emilio G. Cota wrote:
> Signed-off-by: Emilio G. Cota <cota@braap.org>

Applied, thank you!

							Thanx, Paul

> ---
>  advsync/memorybarriers.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
> index e512785..cc11323 100644
> --- a/advsync/memorybarriers.tex
> +++ b/advsync/memorybarriers.tex
> @@ -1667,65 +1667,65 @@ To deal with this, a data dependency barrier must be inserted between the
>  address load and the data load (again with initial values of
>  {\tt \{A = 1, B = 2, C = 3, P = \&A, Q = \&C\}}):
> 
>  \vspace{5pt}
>  \begin{minipage}[t]{\columnwidth}
>  \tt
>  \scriptsize
>  \begin{tabular}{l|p{1.5in}}
>  	CPU 1 &		CPU 2 \\
>  	\hline
>  	B = 4; & \\
>  	<write barrier> & \\
>  	P = \&B; &	\\
>  		&	Q = P; \\
>  		&	<data dependency barrier> \\
>  		&	D = *Q; \\
>  \end{tabular}
>  \end{minipage}
>  \vspace{5pt}
> 
>  This enforces the occurrence of one of the two implications, and prevents the
>  third possibility from arising.
> 
>  Note that this extremely counterintuitive situation arises most easily on
>  machines with split caches, so that, for example, one cache bank processes
>  even-numbered cache lines and the other bank processes odd-numbered cache
>  lines.
>  The pointer \co{P} might be stored in an odd-numbered cache line, and the
>  variable \co{B} might be stored in an even-numbered cache line.  Then, if the
>  even-numbered bank of the reading CPU's cache is extremely busy while the
>  odd-numbered bank is idle, one can see the new value of the
>  pointer \co{P} (which is \co{&B}),
> -but the old value of the variable \co{B} (which is 1).
> +but the old value of the variable \co{B} (which is 2).
> 
>  Another example of where data dependency barriers might by required is where a
>  number is read from memory and then used to calculate the index for an array
>  access with initial values
>  {\tt \{M[0] = 1, M[1] = 2, M[3] = 3, P = 0, Q = 3\}}:
> 
>  \vspace{5pt}
>  \begin{minipage}[t]{\columnwidth}
>  \tt
>  \scriptsize
>  \begin{tabular}{l|p{1.5in}}
>  	CPU 1 &		CPU 2 \\
>  	\hline
>  	M[1] = 4; & \\
>  	<write barrier> & \\
>  	P = 1;	&	\\
>  		&	Q = P; \\
>  		&	<data dependency barrier> \\
>  		&	D = M[Q]; \\
>  \end{tabular}
>  \end{minipage}
>  \vspace{5pt}
> 
>  The data dependency barrier is very important to the Linux kernel's
>  RCU system, for example,
>  see \co{rcu_dereference()} in \url{include/linux/rcupdate.h}.
>  This permits the current
>  target of an RCU'd pointer to be replaced with a new modified target, without
>  the replacement target appearing to be incompletely initialised.
> 
>  See also
>  Section~\ref{sec:advsync:Cache Coherency}
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe perfbook" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>