From 3e726103d0b0b531ea19c5775e64bd7f70e9fb1a Mon Sep 17 00:00:00 2001
From: xmh0511 <970252187@qq.com>
Date: Fri, 8 Nov 2024 17:39:57 +0800
Subject: [PATCH 1/2] change total order to strict total order

---
 source/basic.tex | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/basic.tex b/source/basic.tex
index a3020c43c3..6a7eb72d73 100644
--- a/source/basic.tex
+++ b/source/basic.tex
@@ -6201,11 +6201,11 @@
 
 \pnum
 All modifications to a particular atomic object $M$ occur in some
-particular total order, called the \defn{modification order} of $M$.
+particular strict total order, called the \defn{modification order} of $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
+strict total order for all objects. In general this will be impossible since different
 threads can observe modifications to different objects in inconsistent orders.
 \end{note}
 
@@ -6231,7 +6231,7 @@
 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
+on a given mutex occur in a single strict total order. Each mutex acquisition ``reads
 the value written'' by the last mutex release.
 \end{note}
 

From 1a162068a602c0fe29cf0acac01e85c869c19ed5 Mon Sep 17 00:00:00 2001
From: xmh0511 <970252187@qq.com>
Date: Fri, 8 Nov 2024 17:43:20 +0800
Subject: [PATCH 2/2] change total orde to strict total order

---
 source/threads.tex | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/source/threads.tex b/source/threads.tex
index 7bab867c50..e259f2c156 100644
--- a/source/threads.tex
+++ b/source/threads.tex
@@ -1572,7 +1572,7 @@
 \begin{itemdescr}
 \pnum
 Let $P(\tcode{x}, \tcode{y})$ be
-an unspecified total ordering over \tcode{thread::id}
+an unspecified strict total ordering over \tcode{thread::id}
 as described in \ref{alg.sorting}.
 
 \pnum
@@ -2858,7 +2858,7 @@
 \end{itemize}
 
 \pnum
-There is a single total order $S$
+There is a single strict total order $S$
 on all \tcode{memory_order::seq_cst} operations, including fences,
 that satisfies the following constraints.
 First, if $A$ and $B$ are
@@ -6550,7 +6550,7 @@
 The implementation provides lock and unlock operations, as described below.
 For purposes of determining the existence of a data race, these behave as
 atomic operations\iref{intro.multithread}. The lock and unlock operations on
-a single mutex appears to occur in a single total order.
+a single mutex appears to occur in a single strict total order.
 \begin{note}
 This
 can be viewed as the modification order\iref{intro.multithread} of the
@@ -8645,9 +8645,9 @@
 
 \pnum
 \sync
-For any given \tcode{once_flag}: all active executions occur in a total
+For any given \tcode{once_flag}: all active executions occur in a strict total
 order; completion of an active execution synchronizes with\iref{intro.multithread}
-the start of the next one in this total order; and the returning execution
+the start of the next one in this strict total order; and the returning execution
 synchronizes with the return from all passive executions.
 
 \pnum
@@ -8718,7 +8718,7 @@
 \pnum
 The implementation behaves as if all executions of \tcode{notify_one}, \tcode{notify_all}, and each
 part of the \tcode{wait}, \tcode{wait_for}, and \tcode{wait_until} executions are
-executed in a single unspecified total order consistent with the ``happens before'' order.
+executed in a single unspecified strict total order consistent with the ``happens before'' order.
 
 \pnum
 Condition variable construction and destruction need not be synchronized.