glossary: Add entries for address, control, and data dependencies

Reported-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

1 files changed, 32 insertions, 0 deletions

diff --git a/glossary.tex b/glossary.tex
index b2db8352..8aa36b10 100644
--- a/glossary.tex
+++ b/glossary.tex
@@ -19,6 +19,15 @@
 	Acquiring a lock provides similar memory-ordering semantics,
 	hence the ``acquire'' in ``acquire load''.
 	(See also ``memory barrier'' and ``release store''.)
+\item[\IXGh{Address}{dependency}:]
+	The value returned by a load instruction is used to compute
+	a later memory-reference instruction's address.
+	Address dependencies provide weak memory ordering as described
+	in \cref{sec:memorder:Address Dependencies}.
+	However, because compilers do not understand them, address
+	dependencies are fragile, so please pay close attention to the
+	potential difficulties discussed in
+	\cref{sec:memorder:Address- and Data-Dependency Difficulties}.
 \item[\IXGr{Amdahl's Law}:]
 	If sufficient numbers of CPUs are used to run a job that has both
 	a sequential portion and a concurrent portion, performance and
@@ -192,6 +201,20 @@
 	on \cpageref{sec:app:questions:What is the Difference Between ``Concurrent'' and ``Parallel''?}
 	for a discussion of the recent distinction between these two
 	terms.
+\item[\IXGh{Control}{dependency}:]
+	The value returned by a load instruction is used to determine
+	whether or not a later store instruction is executed.
+	Control dependencies provide weak memory ordering as described
+	in \cref{sec:memorder:Control Dependencies}.
+	However, because compilers do not understand them, control
+	dependencies are exceedingly fragile, so please avoid using them.
+	If severe performance requirements mean that you absolutely must
+	use control dependencies, please carefully consider the potential
+	calamities discussed in
+	\cref{sec:memorder:Control-Dependency Calamities}.
+	Also, please think carefully about alternative approaches that
+	might permit you to meet your performance requirements without
+	use of control dependencies.
 \item[\IXG{Critical Section}:]
 	A section of code guarded by some synchronization mechanism,
 	so that its execution constrained by that primitive.
@@ -201,6 +224,15 @@
 	If a thread is executing in one such critical section,
 	any other threads must wait until the first thread completes
 	before executing any of the critical sections in the set.
+\item[\IXGh{Data}{dependency}:]
+	The value returned by a load instruction is used to compute
+	the value stored by a later store instruction.
+	Data dependencies provide weak memory ordering as described
+	in \cref{sec:memorder:Data Dependencies}.
+	However, because compilers do not understand them, data
+	dependencies are fragile, so please pay close attention to the
+	potential difficulties discussed in
+	\cref{sec:memorder:Address- and Data-Dependency Difficulties}.
 \item[\IXGh{Data}{Locking}:]
 	A scalable locking design in which each instance of a given
 	data structure has its own lock.