原子读操作会导致死锁吗？如何理解原子操作与互斥量的等价表述？

你对这段演讲内容的误解核心是混淆了「内存同步语义等价」和「功能行为等价」的边界，具体解释如下：

1. 所谓“等价”仅针对内存同步约束，而非功能逻辑 #

Herb提到的memory_order_seq_cst下atomic load()等价于mutex.lock()、atomic store()等价于mutex.unlock()，仅指二者的内存可见性约束完全一致，完全不涉及互斥锁的「锁定阻塞」功能：

• 互斥量的lock()操作默认隐含acquire内存语义：所有在lock()之后执行的读写操作，都能看到其他线程之前unlock()同一个互斥量之前的所有写入结果
• 互斥量的unlock()操作默认隐含release内存语义：所有在unlock()之前执行的读写操作，对其他后续lock()同一个互斥量的线程都可见
• 默认memory_order_seq_cst的原子load自带acquire语义，原子store自带release语义，这一层同步约束的效果二者是完全对等的，这就是Herb所说的“等价”的全部含义。

2. 对Herb后续回答的语境澄清 #

你对“如果不写release或者atomic.store()，其他线程永远没有机会运行”的解读完全脱离了当时的讨论场景：
当时观众提问的上下文是用原子变量模拟自旋锁的示例，也就是用std::atomic<bool>实现轻量自旋锁的场景：load()操作用于判断锁是否处于空闲状态、抢锁，store()操作用于释放锁。这种场景下如果线程抢到锁（load判断锁空闲、进入临界区）之后，不执行store释放锁，其他自旋抢锁的线程永远无法拿到锁进入临界区，才会出现“永远没机会运行”的情况，这和普通原子变量读取的场景完全无关。

你给出的示例代码完全符合原子变量的使用逻辑，多个线程同时读取原子变量本来就不会有任何阻塞：

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

std::atomic<int> number{0};

void foo()
{
    while (number != 104) {}
    std::cout << "Number:	" << number << '\n';
}

int main()
{
    std::thread thr1(foo);
    std::thread thr2(foo);
    std::thread thr3(foo);
    std::thread thr4(foo);
    number = 104;
    thr1.join();
    thr2.join();
    thr3.join();
    thr4.join();
}

这段代码里你没有用原子变量模拟锁，自然不存在“读完必须写”的要求，和Herb当时讨论的场景完全不同。

3. 原子操作与互斥量的本质差异 #

• 互斥锁是操作系统级同步原语，lock()抢锁失败会让线程进入休眠阻塞状态，核心作用是实现临界区的排他性访问，存在“持有锁”的状态
• 原子操作是CPU指令级的无锁操作，不管load还是store执行完就立刻结束，不存在任何“持有资源”的状态，多个线程可以同时执行原子load操作，完全不会出现阻塞其他线程访问的情况
• 二者的内存同步语义对应设计，只是为了方便开发者在无锁编程时，用原子操作的内存序模拟锁的同步效果，避免内存乱序带来的逻辑错误，不代表二者功能上可以互相替代。

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