首先，你的核心担忧非常精准：如果仅用memory_order_acquire/memory_order_release实现自旋锁，理论上编译器确实可能对不同锁的操作进行重排，进而引发交叉锁死锁。但别担心，C++标准和正确的锁实现有办法规避这个问题，下面一步步拆解：

1. C++标准如何防范这类问题？ #

C++标准本身并没有直接禁止跨锁的操作重排，但它对互斥锁的语义有严格要求，同时提供了更强的内存顺序来约束这种重排：

• 首先，as-if规则允许单线程行为等价的重排，但跨锁重排后在多线程场景下出现的死锁，并不违反as-if规则——因为as-if只保证单线程行为一致，多线程的并发行为本来就是未定义的，除非有明确的同步约束。
• 真正的关键是：标准库中的std::mutex实现会使用比acquire/release更强的内存约束（通常是memory_order_seq_cst），或者插入显式内存屏障，确保同一线程中不同锁的lock()/unlock()操作严格按照程序顺序执行，不会被重排。

简单说：标准库的互斥锁已经帮你处理了这个问题，但你自己实现自旋锁时如果只用到acquire/release，就需要额外处理。

2. 如何实现无此问题的自旋锁？ #

要避免跨锁操作被重排，你需要强化锁操作的内存顺序，确保同一线程中的锁操作不会乱序。最直接的方案是把原子操作的内存顺序改成memory_order_seq_cst：

#include <atomic>
#include <thread>

struct safe_mutex {
    void lock() {
        // 使用seq_cst确保所有锁操作的全局顺序和线程内顺序一致
        while (lock.test_and_set(std::memory_order_seq_cst)) {
            std::this_thread::yield();
        }
    }
    void unlock() {
        lock.clear(std::memory_order_seq_cst);
    }
    std::atomic_flag lock = ATOMIC_FLAG_INIT; // C++20前需要显式初始化
};

memory_order_seq_cst的核心特性是：

• 所有seq_cst操作会形成一个全局的总顺序；
• 在同一个线程中，seq_cst操作严格按照程序顺序执行，不会被编译器或CPU重排。

这样一来，threadA中的m1.unlock()和m2.lock()就不会被重排，你担心的死锁场景就不会发生。

另一种方案是在unlock()中添加显式的内存栅栏，性能比全用seq_cst稍好：

void unlock() {
    lock.clear(std::memory_order_release);
    // 栅栏确保后续操作不会重排到release之前
    std::atomic_thread_fence(std::memory_order_seq_cst);
}

3. 原始的acquire/release互斥锁适用哪些场景？ #

虽然原始实现存在潜在的重排风险，但在一些特定场景下是完全安全且性能更好的：

• 单锁场景：如果程序中只用到一个互斥锁，不存在交叉获取多个锁的情况，重排不会引发任何问题，acquire/release的轻量级语义反而能带来更好的性能。
• 固定锁顺序场景：所有线程都严格按照相同的顺序获取多个锁（比如必须先锁m1再锁m2），即使出现跨锁重排，也不会形成循环等待，自然不会死锁。
• 无锁依赖场景：每个线程的锁操作都是独立的，不存在一个线程解锁A后再锁B，另一个线程解锁B后再锁A的情况。

在这些场景下，acquire/release的自旋锁是高效且安全的选择。

内容的提问来源于stack exchange，提问作者Alex Guteniev