关于实现（编译器/CPU）能否跨潜在无限循环重排指令的技术问询（附代码示例）

咱们先把你的代码贴出来，方便对照分析：

#include <iostream>
#include <thread>
#include <atomic>
#include <chrono>
using namespace std::chrono_literals;

void do_something(){
    // balabala
}

int main(){
    std::atomic<int> state = {1};
    std::thread t1([&](){
        int expected = 0;
        while(!state.compare_exchange_strong(expected,1,std::memory_order::acq_rel,std::memory_order::relaxed)){
            expected = 0;
        }
        do_something();
    });
    std::thread t2([&](){
        std::this_thread::sleep_for(2000ms);
        state.store(0,std::memory_order::release);
    });
    t1.join();
    t2.join();
}

好，现在来逐个拆解你的问题：

核心疑问：编译器/CPU能不能把do_something()重排到潜在无限循环的前面？ #

首先得明确两个层面的限制：编译器的优化规则和CPU的投机执行约束，还有C++标准里的as-if规则和循环终止性的判定。

1. 编译器层面的重排限制

C++标准的as-if规则是底线：编译器生成的代码必须和抽象机的可观察行为完全一致。那针对你的场景：

• 如果do_something()有可观察行为（比如打印日志、写全局变量、做I/O操作、调用带副作用的函数）：这种重排绝对不允许。因为抽象机里do_something()是在循环退出后才执行的，提前执行会直接改变可观察行为的顺序，违反as-if规则。
• 如果do_something()完全没有可观察行为（比如空函数，或者只做了一些不涉及外部状态的纯计算）：理论上编译器可以直接把它优化掉，但也不能把它重排到循环前面——因为编译器无法证明这个循环一定会终止（它不知道其他线程会修改state原子变量），所以必须假设循环可能无限执行，而循环后的代码在抽象机里永远不会被执行，提前执行就会违背抽象机的行为逻辑。

2. CPU层面的投机执行

CPU的投机执行是硬件层面的优化，它会预测分支走向，提前执行可能的后续代码，但有个硬约束：如果预测错误，必须能完全回滚所有投机操作，不会留下任何可见的副作用。针对你的场景：

• 如果do_something()有可观察行为：CPU可能会投机执行它，但这些操作会被暂存到硬件缓冲区（比如store buffer）里，只有当确认循环真的退出后，才会提交这些操作到内存或执行I/O。如果预测错误（循环还在执行），CPU会直接回滚这些投机操作，不会产生任何可见影响，所以这种行为是允许的，不会违反抽象机的行为。
• 如果do_something()没有可观察行为：CPU投机执行它也不会有任何问题，反正没有副作用，就算回滚也不会有影响——不过硬件通常也不会浪费周期去执行这种没有意义的代码，大概率会直接优化掉。

补充：CAS操作的特性会不会影响这个结论？ #

你提到CAS失败时和relaxed load等价，但这并不改变循环的终止性判定。编译器不知道其他线程会修改state，所以它必须假设这个循环可能永远执行下去，因此不能把循环后的代码提前到循环前面。哪怕CAS的失败路径是relaxed load，只要循环的终止性无法被编译器证明，这种重排就被禁止。

总结一下 #

• 编译器层面：不管do_something()有没有可观察行为，都不能把它重排到这个潜在无限循环的前面——除非编译器能100%证明循环一定会终止，而你的代码里编译器做不到这一点。
• CPU层面：硬件的投机执行可能会提前执行do_something()，但会严格保证不破坏可观察行为的顺序，所以是允许的。
• do_something()的实现确实会影响细节，但核心的约束逻辑不变：只要有可观察行为，就不会出现可见的提前执行；没有的话，就算被投机执行也不会有任何影响。

内容来源于stack exchange