diff --git a/source/basic.tex b/source/basic.tex
index bcd8df1d1f..7ff4608308 100644
--- a/source/basic.tex
+++ b/source/basic.tex
@@ -4655,17 +4655,27 @@
 memory location.
 
 \pnum
-The library defines a number of atomic operations\iref{atomics} and
-operations on mutexes\iref{thread} that are specially identified as
-synchronization operations. These operations play a special role in making
-assignments in one thread visible to another. A synchronization operation on one
-or more memory locations is either a consume operation, an acquire operation, a
-release operation, or both an acquire and release operation. A synchronization
-operation without an associated memory location is a fence and can be either an
-acquire fence, a release fence, or both an acquire and release fence. In
-addition, there are relaxed atomic operations, which are not synchronization
-operations, and atomic read-modify-write operations, which have special
-characteristics. \begin{note} For example, a call that acquires a mutex will
+All modifications to a particular atomic object \placeholder{M} occur in some
+particular total order, called the \defn{modification order} of \placeholder{M}.
+\begin{note} There is a separate order for each
+atomic object. There is no requirement that these can be combined into a single
+total order for all objects. In general this will be impossible since different
+threads may observe modifications to different objects in inconsistent orders.
+\end{note}
+
+\pnum
+Certain library calls \defn{synchronize with} other library calls performed by
+another thread.
+Such calls are also known as
+\defnx{synchronization operations}{synchronization operation}.
+\begin{note} Except in the specified cases, reading a later value does not
+necessarily ensure visibility as described below. Such a requirement would
+sometimes interfere with efficient implementation. \end{note} \begin{note} The
+specifications of the synchronization operations
+(\ref{support.signal}, \ref{util.smartptr.atomic}, \ref{atomics.order},
+\ref{atomics.fences}, \ref{thread}) define when one reads the value
+written by another. For atomic objects, the definition is clear.
+A call that acquires a mutex will
 perform an acquire operation on the locations comprising the mutex.
 Correspondingly, a call that releases the same mutex will perform a release
 operation on those same locations. Informally, performing a release operation on
@@ -4673,17 +4683,9 @@
 \indextext{side effects}%
 side effects on other memory locations to become visible
 to other threads that later perform a consume or an acquire operation on
-\placeholder{A}. ``Relaxed'' atomic operations are not synchronization operations even
-though, like synchronization operations, they cannot contribute to data races.
-\end{note}
-
-\pnum
-All modifications to a particular atomic object \placeholder{M} occur in some
-particular total order, called the \defn{modification order} of \placeholder{M}.
-\begin{note} There is a separate order for each
-atomic object. There is no requirement that these can be combined into a single
-total order for all objects. In general this will be impossible since different
-threads may observe modifications to different objects in inconsistent orders.
+\placeholder{A}. ``Relaxed'' atomic operations are not synchronization
+operations even though, like synchronization operations, they cannot
+contribute to data races.
 \end{note}
 
 \pnum
@@ -4699,18 +4701,6 @@
 \item is an atomic read-modify-write operation.
 \end{itemize}
 
-\pnum
-Certain library calls \defn{synchronize with} other library calls performed by
-another thread. For example, an atomic store-release synchronizes with a
-load-acquire that takes its value from the store\iref{atomics.order}.
-\begin{note} Except in the specified cases, reading a later value does not
-necessarily ensure visibility as described below. Such a requirement would
-sometimes interfere with efficient implementation. \end{note} \begin{note} The
-specifications of the synchronization operations define when one reads the value
-written by another. For atomic objects, the definition is clear. All operations
-on a given mutex occur in a single total order. Each mutex acquisition ``reads
-the value written'' by the last mutex release. \end{note}
-
 \pnum
 An evaluation \placeholder{A} \defn{carries a dependency} to an evaluation \placeholder{B} if