原子变量

定义

当两个线程同时修改原子变量时，以下操作会发生：

原子性：原子变量的修改是原子的，即每次修改都是一个不可分割的操作。这意味着在任何时刻，只有一个线程能够成功地修改原子变量，而不会出现竞争条件。

同步机制：原子变量使用硬件级别的同步机制（如锁、比较并交换操作等）来确保修改的原子性。这些机制确保线程在修改原子变量时不会干扰其他线程的操作。

内存可见性：原子变量的修改会确保内存可见性，即一个线程对原子变量的修改会立即对其他线程可见。这意味着其他线程可以看到最新的修改结果，而不会读取到过时的数据。

举个例子，假设我们有一个原子变量 std::atomic<int> counter，两个线程同时执行 counter++ 操作：

atomic1.cppview raw

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> counter(0);

void increment() {
    for (int i = 0; i < 1000; ++i) {
        counter++;
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

在这个例子中：

两个线程 t1 和 t2 同时执行 increment 函数，尝试修改原子变量 counter。
原子性 确保每次 counter++ 操作都是不可分割的，避免竞争条件。
同步机制 确保两个线程不会同时修改 counter，而是一个线程成功修改后，另一个线程才能继续修改。
内存可见性 确保 counter 的最新值对两个线程都是可见的。

实现机制

让我们深入探讨一下两个线程同时修改原子变量时的底层机制。

1. 原子操作的硬件支持
   原子操作通常由硬件指令支持，这些指令确保操作的原子性。例如，x86架构提供了 LOCK 前缀，用于确保指令在多处理器环境中的原子性。常见的原子指令包括 LOCK XADD（原子加法）和 LOCK CMPXCHG（原子比较并交换）。

2. 缓存一致性协议
   多核处理器使用缓存一致性协议（如MESI协议）来确保各个处理器缓存中的数据一致性。当一个处理器修改原子变量时，缓存一致性协议会确保其他处理器的缓存中对应的数据无效或更新。

3. 内存屏障
   内存屏障（Memory Barrier）是一种指令，用于防止编译器和处理器对内存操作进行重排序。原子操作通常会使用内存屏障来确保操作的顺序性和可见性。例如，std::atomic 在实现时会使用内存屏障来确保操作的正确性。

4. 比较并交换（CAS）
   比较并交换（Compare-And-Swap, CAS）是一种常用的原子操作，它通过比较变量的当前值和预期值，如果相等则更新变量的值。CAS操作是无锁编程的基础，用于实现许多并发数据结构。

5. 伪代码示例
   以下是一个伪代码示例，展示了CAS操作的工作原理：

cas_mock.cppview raw

bool compare_and_swap(int* ptr, int old_value, int new_value) {
    if (*ptr == old_value) {
        *ptr = new_value;
        return true;
    }
    return false;
}

在多线程环境中，CAS操作可以确保只有一个线程成功修改变量的值，而其他线程会失败并重试。

6. 实际应用
   在实际应用中，原子变量的操作可能如下所示：

atomic2.cppview raw

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> counter(0);

void increment() {
    for (int i = 0; i < 1000; ++i) {
        int expected = counter.load();
        while (!counter.compare_exchange_weak(expected, expected + 1)) {
            // 重试，直到成功
        }
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

在这个例子中，compare_exchange_weak 使用CAS操作来确保 counter 的原子性修改。每次修改失败时，线程会重试，直到成功。

缓存一致性协议

缓存一致性协议是确保多核处理器中各个缓存之间数据一致性的机制。最常见的缓存一致性协议是MESI协议。让我们详细解释一下。

MESI协议

MESI协议是由四种状态组成的缓存一致性协议，每个缓存行（Cache Line）可以处于以下四种状态之一：

• Modified（修改）：缓存行中的数据已被修改，与主内存中的数据不一致，且该数据仅存在于当前缓存中。
• Exclusive（独占）：缓存行中的数据与主内存中的数据一致，且该数据仅存在于当前缓存中。
• Shared（共享）：缓存行中的数据与主内存中的数据一致，且该数据可能存在于多个缓存中。
• Invalid（无效）：缓存行中的数据无效。

状态转换

缓存行的状态会根据不同的操作进行转换。以下是一些常见的状态转换：

从主内存读取数据：如果一个缓存行处于Invalid状态，当一个处理器读取该数据时，缓存行会变为Shared或Exclusive状态。
修改数据：如果一个缓存行处于Shared或Exclusive状态，当一个处理器修改该数据时，缓存行会变为Modified状态，并通知其他缓存将该缓存行置为Invalid状态。
写回数据：如果一个缓存行处于Modified状态，当该缓存行被替换时，数据会被写回主内存，缓存行变为Invalid状态。

工作原理

假设有三个处理器A、B和C，它们各自有自己的缓存。主内存中有一个变量x，初始值为0。

读取数据：

处理器A从主内存读取x，缓存行状态变为Exclusive。
处理器B从主内存读取x，处理器A检测到冲突，将缓存行状态变为Shared，处理器B的缓存行状态也变为Shared。
修改数据：

处理器A修改x，缓存行状态变为Modified，并通知处理器B将其缓存行状态变为Invalid。
处理器B尝试读取x时，检测到缓存行无效，从主内存重新读取数据。

写回数据：

处理器A将修改后的数据写回主内存，缓存行状态变为Invalid。

优化和问题

缓存一致性协议通过总线嗅探（Bus Snooping）和状态机机制来实现数据的一致性，但也会引入一些性能问题，如总线带宽压力和处理器等待时间。为了解决这些问题，现代处理器引入了存储缓冲区（Store Buffer）和写回策略（Write Back）等优化技术。

CAS

比较并交换（Compare-And-Swap, CAS）操作在并发编程中有许多好处：

1. 无锁编程
   CAS操作是无锁编程的基础，它允许多个线程在不使用锁的情况下安全地修改共享数据。无锁编程可以减少锁的开销，避免死锁，提高系统的并发性能。

2. 原子性
   CAS操作是原子的，即它确保比较和交换操作在硬件级别上是不可分割的。这意味着在任何时刻，只有一个线程能够成功地修改变量的值，避免竞争条件。

3. 高效性
   CAS操作通常由硬件指令支持（如x86架构中的 LOCK CMPXCHG 指令），这些指令非常高效，能够快速完成比较和交换操作。相比于使用锁，CAS操作的开销更低。

4. 可扩展性
   CAS操作允许多个线程同时尝试修改变量，而不会阻塞其他线程。这种特性使得CAS操作在高并发环境中具有良好的可扩展性，能够处理大量线程的并发访问。

5. 实现复杂的并发数据结构
   CAS操作可以用于实现复杂的并发数据结构，如无锁队列、无锁栈等。这些数据结构能够在高并发环境中提供高效的操作，而不会引入锁的开销。

以下是一个使用CAS操作实现无锁计数器的示例：

cas_counter.cppview raw

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> counter(0);

void increment() {
    for (int i = 0; i < 1000; ++i) {
        int expected = counter.load();
        while (!counter.compare_exchange_weak(expected, expected + 1)) {
            // 重试，直到成功
        }
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

在这个例子中，compare_exchange_weak 使用CAS操作来确保 counter 的原子性修改。每次修改失败时，线程会重试，直到成功。

compare_exchange_weak 和 fetch_add

compare_exchange_weak 和 fetch_add 是两种不同的原子操作，它们在功能和使用场景上有明显的区别。让我们详细解释一下它们的区别以及如何选择。

compare_exchange_weak

功能：

compare_exchange_weak 是一种CAS（Compare-And-Swap）操作，用于比较原子变量的当前值与预期值，如果相等，则将新值存储到变量中，并返回 true；如果不相等，则返回 false 并更新预期值。
该操作允许偶尔的失败（即使当前值与预期值相等，也可能返回 false），这在一些循环算法中是可以接受的。

使用场景：

适用于需要在循环中反复尝试更新变量的场景，例如实现无锁数据结构（如无锁队列、栈等）。
在高并发环境中，compare_exchange_weak 通常比 compare_exchange_strong 性能更高，因为它允许偶尔的失败，从而减少了总线锁定的开销.

fetch_add

功能：

fetch_add 是一种原子加法操作，它将给定的值加到原子变量的当前值中，并返回变量的旧值。
该操作是原子的，确保在多线程环境中不会出现竞争条件。

使用场景：

适用于简单的计数器或累加器场景，例如统计访问次数、累加总和等。
在需要对变量进行简单的加法操作时，fetch_add 是一个高效的选择2.

如何选择

选择 compare_exchange_weak 还是 fetch_add 取决于具体的使用场景和需求：

如果需要实现复杂的无锁数据结构（如无锁队列、栈等），并且需要反复尝试更新变量，选择 compare_exchange_weak。
如果需要对变量进行简单的加法操作（如计数器、累加器），选择 fetch_add。
示例代码
以下是使用 compare_exchange_weak 和 fetch_add 的示例代码：

compare_exchange_weak 示例：

compare_exchange_weak_eg.cppview raw

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> counter(0);

void increment() {
    for (int i = 0; i < 1000; ++i) {
        int expected = counter.load();
        while (!counter.compare_exchange_weak(expected, expected + 1)) {
            // 重试，直到成功
        }
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

fetch_add 示例：

fetch_add_eg.cppview raw

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> counter(0);

void increment() {
    for (int i = 0; i < 1000; ++i) {
        counter.fetch_add(1);
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

如果我们只需要简单地递增计数器，并且没有其他条件限制，fetch_add 确实是一个更直接和高效的选择。fetch_add 能够确保每次递增操作都是原子的，避免了竞争条件。

然而，在某些特定场景下，compare_exchange_weak 可能更为合适。例如，当我们需要基于特定条件进行更新时，compare_exchange_weak 可以确保只有在满足条件时才进行更新操作。

示例：基于条件的更新
假设我们有一个计数器，需要在满足特定条件时进行递增操作：

cas_case.cppview raw

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> counter(0);

void conditional_increment() {
    for (int i = 0; i < 1000; ++i) {
        int expected = counter.load();
        while (expected < 500 && !counter.compare_exchange_weak(expected, expected + 1)) {
            // 重试，直到成功或条件不满足
        }
    }
}

int main() {
    std::thread t1(conditional_increment);
    std::thread t2(conditional_increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

在这个例子中，只有当 counter 的值小于500时，才会进行递增操作。compare_exchange_weak 确保条件更新的原子性和安全性。

使用 fetch_add 的场景
如果我们不需要基于条件进行更新，只是简单地递增计数器，那么 fetch_add 是一个更好的选择：

fetch_add_case.cppview raw

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> counter(0);

void increment() {
    for (int i = 0; i < 1000; ++i) {
        counter.fetch_add(1);
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

在这个例子中，fetch_add 确保每次递增操作都是原子的，避免了竞争条件。

总结来说，如果你的操作只是简单的递增，fetch_add 是更高效的选择；如果需要基于条件进行更新，compare_exchange_weak 则更为合适。

ABA

ABA问题在并发编程中是一个常见的问题，尤其是在使用CAS（Compare-And-Swap）操作时。ABA问题的本质是一个变量的值在两次比较之间发生了变化，但最终值又回到了原始值，导致CAS操作无法检测到这种变化。为了避免ABA问题，可以使用带有版本号或标记的原子引用，例如 AtomicStampedReference。

示例：使用 AtomicStampedReference 避免ABA问题
以下是一个使用 AtomicStampedReference 避免ABA问题的示例：

atomic_stamped_reference.cppview raw

#include <atomic>
#include <thread>
#include <iostream>
#include <vector>

std::atomic<int> counter(0);
std::atomic<int> stamp(0);

void conditional_increment() {
    for (int i = 0; i < 1000; ++i) {
        int expected = counter.load();
        int expected_stamp = stamp.load();
        while (expected < 500 && !counter.compare_exchange_weak(expected, expected + 1) && !stamp.compare_exchange_weak(expected_stamp, expected_stamp + 1)) {
            // 重试，直到成功或条件不满足
        }
    }
}

int main() {
    std::thread t1(conditional_increment);
    std::thread t2(conditional_increment);

    t1.join();
    t2.join();

    std::cout << "Final counter value: " << counter << std::endl;
    std::cout << "Final stamp value: " << stamp << std::endl;
    return 0;
}

在这个例子中，我们使用了一个额外的 stamp 变量来记录每次更新的版本号。每次更新 counter 时，同时更新 stamp。这样，即使 counter 的值回到了原始值，stamp 的值也会不同，从而避免了ABA问题。

解释
版本号：每次更新 counter 时，同时更新 stamp，确保每次更新都有一个唯一的版本号。
CAS操作：使用 compare_exchange_weak 确保 counter 和 stamp 的更新是原子的。
重试机制：如果CAS操作失败，线程会重试，直到成功或条件不满足。
这种方法通过引入版本号或标记，确保即使变量的值回到了原始值，版本号也会不同，从而避免了ABA问题。

ABA问题不仅存在于CAS操作中，还可能在其他并发编程场景中出现。以下是一些可能出现ABA问题的情景：

1. 双重检查锁定（Double-Checked Locking）
   在双重检查锁定模式中，ABA问题可能会导致错误的判断。例如，在初始化单例对象时，如果两个线程同时检查对象是否为空，并且一个线程在检查后立即创建对象，而另一个线程在检查后发现对象已经被创建并且再次检查时发现对象为空，这可能会导致错误的初始化。

2. 无锁队列和栈
   在无锁队列和栈的实现中，ABA问题可能会导致节点的插入和删除操作出现错误。例如，一个线程在删除节点时，另一个线程可能会插入和删除相同的节点，导致第一个线程无法正确判断节点的状态。

3. 版本控制
   在版本控制系统中，ABA问题可能会导致错误的版本判断。例如，一个线程在检查版本号时，另一个线程可能会更新版本号并且再次更新回原始版本号，导致第一个线程无法正确判断版本是否被修改。

解决方案
为了避免ABA问题，可以使用以下解决方案：

版本号或标记：使用版本号或标记来记录每次更新的状态。例如，使用 AtomicStampedReference 来确保每次更新都有一个唯一的版本号。
时间戳：使用时间戳来记录每次更新的时间，确保每次更新都有一个唯一的时间标记。
逻辑时钟：使用逻辑时钟来记录每次更新的顺序，确保每次更新都有一个唯一的顺序标记。
示例：使用 AtomicStampedReference 避免ABA问题
以下是一个使用 AtomicStampedReference 避免ABA问题的示例：

atomic_stamped_reference.javaview raw

import java.util.concurrent.atomic.AtomicStampedReference;

public class ABAExample {
    private static AtomicStampedReference<Integer> atomicStampedRef = new AtomicStampedReference<>(0, 0);

    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            int stamp = atomicStampedRef.getStamp();
            Integer value = atomicStampedRef.getReference();
            System.out.println("Thread 1 initial value: " + value + ", stamp: " + stamp);
            atomicStampedRef.compareAndSet(value, value + 1, stamp, stamp + 1);
            System.out.println("Thread 1 updated value: " + atomicStampedRef.getReference() + ", stamp: " + atomicStampedRef.getStamp());
        });

        Thread t2 = new Thread(() -> {
            int stamp = atomicStampedRef.getStamp();
            Integer value = atomicStampedRef.getReference();
            System.out.println("Thread 2 initial value: " + value + ", stamp: " + stamp);
            atomicStampedRef.compareAndSet(value, value + 1, stamp, stamp + 1);
            System.out.println("Thread 2 updated value: " + atomicStampedRef.getReference() + ", stamp: " + atomicStampedRef.getStamp());
        });

        t1.start();
        t2.start();
    }
}

在这个例子中，AtomicStampedReference 使用版本号来避免ABA问题，确保每次更新都有一个唯一的版本号。

C++ 标准库中没有直接等同于 Java 的 AtomicStampedReference 的类，但你可以通过组合 std::atomic 和自定义结构体来实现类似的功能。以下是一个示例，展示如何在 C++ 中实现带有版本号的原子引用，以避免 ABA 问题：

示例：实现带有版本号的原子引用

cas_with_version.cppview raw

#include <atomic>
#include <iostream>
#include <thread>

struct StampedValue {
    int value;
    int stamp;
};

std::atomic<StampedValue> atomicStampedValue{StampedValue{0, 0}};

void increment() {
    for (int i = 0; i < 1000; ++i) {
        StampedValue expected = atomicStampedValue.load();
        StampedValue newValue;
        do {
            newValue = {expected.value + 1, expected.stamp + 1};
        } while (!atomicStampedValue.compare_exchange_weak(expected, newValue));
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    StampedValue finalValue = atomicStampedValue.load();
    std::cout << "Final value: " << finalValue.value << ", Final stamp: " << finalValue.stamp << std::endl;
    return 0;
}

解释
StampedValue 结构体：包含一个值和一个版本号（或时间戳）。
std::atomic：使用 std::atomic 包装 StampedValue 结构体，以确保原子性操作。
compare_exchange_weak：在更新值和版本号时使用 CAS 操作，确保操作的原子性和避免 ABA 问题。
使用场景
这种方法适用于需要避免 ABA 问题的场景，例如无锁队列、无锁栈等复杂并发数据结构。

compare_exchange_weak 和 compare_exchange_strong

区别
可靠性：

compare_exchange_weak：允许偶尔失败，即使当前值与期望值相等，也可能返回 false。这种设计是为了提高性能，适用于循环中的自旋锁等场景。
compare_exchange_strong：保证操作成功，如果当前值与期望值相等，则一定返回 true。适用于需要确保操作成功的场景。
性能：

compare_exchange_weak：通常比 compare_exchange_strong 性能更高，因为它允许偶尔失败。
compare_exchange_strong：在某些平台上性能可能较低，因为它需要确保操作成功。
适用场景
compare_exchange_weak：

• 适用于循环中的自旋锁。
• 适用于高性能要求的场景。

compare_exchange_strong：

• 适用于需要确保操作成功的场景。
• 适用于线程同步。

compare_exchange_weak 允许虚假失败的底层实现基于 CAS（Compare-And-Swap） 操作和硬件指令的特性。以下是详细解释：

CAS操作
CAS 操作有三个参数：内存地址、预期值和新值。其基本原理是：

比较内存地址中的值是否与预期值相等。
如果相等，则将内存地址中的值更新为新值。
如果不相等，则不做任何操作，并返回当前内存地址中的值。
虚假失败的原因
compare_exchange_weak 允许虚假失败，即使当前值与预期值相等，也可能返回 false。这种情况通常发生在以下几种情况：

缓存一致性问题：

在多核处理器中，缓存一致性协议可能导致 CAS 操作失败，即使内存中的值没有改变。例如，在 ARM 架构中，使用 LDXR/STXR 指令时，其他线程对同一缓存行的访问可能导致 CAS 操作失败1。
硬件指令的实现：

在某些平台上，CAS 操作可能被实现为单次 LL/SC（Load-Linked/Store-Conditional）尝试。这种实现允许 CAS 操作偶尔失败，以提高性能

为什么compare_exchange_strong不被用于实现自旋锁？
Copilot said:
Copilot
compare_exchange_strong 通常不用于实现自旋锁，主要原因在于其性能和设计目的：

性能
compare_exchange_strong 保证操作成功，如果当前值与预期值相等，则一定返回 true1。这种保证需要更多的硬件资源和时间来完成操作，可能导致性能下降1。
compare_exchange_weak 允许偶尔失败，即使当前值与预期值相等，也可能返回 false1。这种设计减少了硬件资源的消耗，提高了性能1。
设计目的
自旋锁 的设计目的是在短时间内频繁尝试获取锁，而不是长时间等待。因此，自旋锁更适合使用 compare_exchange_weak，因为它可以在失败时快速重试1。
compare_exchange_strong 更适合需要确保操作成功的场景，如线程同步1。在这些场景中，操作的成功率比性能更重要。
代码示例
以下是一个使用 compare_exchange_weak 实现自旋锁的示例：

cas_spin_lock.cppview raw

class SpinLock {
private:
    std::atomic<bool> flag = {false};
public:
    void lock() {
        bool expected = false;
        while (!flag.compare_exchange_weak(expected, true, std::memory_order_acquire)) {
            expected = false;
        }
    }
    void unlock() {
        flag.store(false, std::memory_order_release);
    }
};

在这个示例中，compare_exchange_weak 被用来实现自旋锁，因为它在失败时可以快速重试，从而提高性能

内存屏障

内存屏障（Memory Barrier），也被称为内存栅栏（Memory Fence）或内存围栏（Memory Fence），是一种硬件或软件的同步机制，用于在并发系统中保持内存操作的顺序性123。这是多核和多线程环境中至关重要的，因为现代处理器会对指令进行重排序以提高执行效率123。

内存屏障的作用
防止指令重排序：

编译器和处理器可能会对指令进行重排序，以优化性能12。内存屏障确保特定的内存操作在屏障之前完成，而不会被重排序到屏障之后12。
保证内存可见性：

在多线程环境中，一个线程对内存的修改必须对其他线程可见12。内存屏障确保在屏障之前的所有写操作对其他线程可见12。
类型
加载屏障（Load Barrier）：

确保在屏障之前的所有加载操作完成后，才开始执行屏障之后的加载操作12。
存储屏障（Store Barrier）：

确保在屏障之前的所有存储操作完成后，才开始执行屏障之后的存储操作12。
全屏障（Full Barrier）：

结合了加载屏障和存储屏障的功能，确保在屏障之前的所有加载和存储操作完成后，才开始执行屏障之后的加载和存储操作12。
代码示例
以下是一个简单的代码示例，展示了如何使用内存屏障：

memory_barrier.cppview raw

#include <atomic>

std::atomic<int> a{0};
std::atomic<int> b{0};

void thread1() {
    a.store(1, std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_seq_cst);  // 全屏障
    b.store(1, std::memory_order_relaxed);
}

void thread2() {
    while (b.load(std::memory_order_relaxed) == 0);
    std::atomic_thread_fence(std::memory_order_seq_cst);  // 全屏障
    assert(a.load(std::memory_order_relaxed) == 1);
}

在这个示例中，std::atomic_thread_fence 用于插入内存屏障，确保在屏障之前的存储操作完成后，才开始执行屏障之后的存储操作

内存序

内存序（Memory Order）描述了在多线程环境中，内存操作的顺序和可见性。它决定了一个线程对内存的修改何时以及如何对其他线程可见。C++11 引入了六种内存序，以便程序员在并发编程中根据需求选择合适的同步机制123。

六种内存序
memory_order_relaxed：

只保证当前操作的原子性，不考虑线程间的同步12。适用于不需要同步的场景，如计数器的增加12。
memory_order_consume：

确保当前操作依赖的所有写操作在此操作之前完成12。主要用于依赖关系较强的场景12。
memory_order_acquire：

确保在此操作之后的所有读写操作不会被重排序到此操作之前12。常用于获取锁的操作12。
memory_order_release：

确保在此操作之前的所有读写操作不会被重排序到此操作之后12。常用于释放锁的操作12。
memory_order_acq_rel：

结合了 acquire 和 release 的语义，确保在此操作之前的写操作不会被重排序到此操作之后，同时在此操作之后的读操作不会被重排序到此操作之前12。适用于读-修改-写操作12。
memory_order_seq_cst：

顺序一致性，确保所有线程看到的内存操作顺序一致12。这是最严格的内存序，适用于需要强一致性的场景12。
代码示例
以下是一个简单的代码示例，展示了如何使用不同的内存序：

memory_order.cppview raw

#include <atomic>
#include <thread>
#include <cassert>

std::atomic<int> data{0};
std::atomic<bool> ready{false};

void producer() {
    data.store(42, std::memory_order_relaxed);
    ready.store(true, std::memory_order_release);
}

void consumer() {
    while (!ready.load(std::memory_order_acquire));
    assert(data.load(std::memory_order_relaxed) == 42);
}

int main() {
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join();
    t2.join();
    return 0;
}

在这个示例中，producer 线程使用 memory_order_release 来发布数据，而 consumer 线程使用 memory_order_acquire 来确保读取到的数据是最新的

TODO