C++编译器是否可合法合并相邻互斥锁代码？

问题背景 #

先看这段包含相邻互斥锁段的代码：

std::mutex mutex;
int x;

void func() {
    {
        std::lock_guard lock{mutex};
        x++;
    }
    {
        std::lock_guard lock{mutex};
        x++;
    }
}

如果没有互斥锁，编译器显然可以将两次x++合并为x += 2；即使x是std::atomic<int>，这种优化在C++标准中也是合法的（尽管实际编译器可能未实现）。

现在的核心疑问是：带互斥锁时，编译器是否有权将上述func转换为以下形式？

void func() {
    std::lock_guard lock{mutex};
    x += 2;
}

这里的矛盾点在于：

• 从as-if规则出发，优化前后的差异仅依赖线程调度时机，外部无法区分，似乎合法；
• 但这种优化如果极端化，可能将整个程序的互斥锁操作合并为一次全程加锁，对并发应用的性能不利，会不会被标准禁止？

基于C++标准的分析 #

C++标准允许这种优化，核心依据来自以下条款和语义：

1. as-if规则的核心约束 #

C++标准[intro.execution]章节明确了as-if规则：编译器可以执行任何不改变程序可观察行为（observable behavior）的优化。对于本问题：

• 单线程场景下，两次加锁解锁与一次加锁解锁的执行结果完全一致，可观察行为无差异；
• 多线程场景下，互斥锁的核心语义是保证临界区互斥执行。只要所有共享变量x的访问都受同一互斥锁保护，合并前后的代码对其他线程的可观察内存效果等价：其他线程要么看到x修改前的值，要么看到x增加2后的值，无法合法观察到两次增量之间的中间状态——因为中间状态没有经过解锁（release操作）同步到其他线程，标准不保证这种未同步的状态能被其他线程看到。

2. 互斥锁的acquire-release语义 #

C++标准[thread.mutex.requirements.mutex]定义了互斥锁的同步语义：解锁操作是release操作，加锁是acquire操作。

• 分开的两次解锁-加锁序列，对应两次release-acquire同步；合并后则是一次release-acquire。
• 但对于x的修改来说，合并后的代码中，两次x的增量会在同一个临界区内完成，最终的修改结果会在解锁时通过release操作同步到其他线程，和分开执行的最终可见效果完全一致——不会改变其他线程能观察到的x的最终值。

3. 实际编译器未实现的原因 #

虽然标准允许，但Clang、GCC等主流编译器通常不做这种优化，原因包括：

• 优化的分析成本高：需要精确识别相邻的、使用同一互斥锁的临界区，还需确认临界区间没有其他可观察行为（如I/O、调用外部函数）；
• 并发性能的不确定性：合并临界区会延长锁的持有时间，可能降低整体并发度，编译器无法预判用户的性能需求；
• 极端合并场景不会发生：as-if规则只允许不改变可观察行为的优化，如果临界区间存在其他可观察操作（如解锁后打印日志），编译器就不能合并，因为这会改变程序的可观察行为。

内容的提问来源于stack exchange，提问作者MC ΔT