实现TL2事务内存算法时，如何在C++中允许可控数据竞争且避免UB

问题背景 #

在实现事务内存算法TL2时，我们发现该算法允许数据竞争：提交写事务的过程中，读事务可能读取同一内存区域。不过由于成功写入后锁的版本会更新，无效读取的结果会被进一步作废，事务会被中止，我们并不会使用这些无效结果。但C++中的数据竞争会直接导致未定义行为（UB），想知道是否有办法告知编译器此类数据竞争是可接受的，从而在形式上消除程序中的UB？

已知一种可行方案是将事务内存分配为std::atomic数组：

auto memory_region = new std::atomic<char>[size];

并使用带有std::memory_order_relaxed的原子操作来操作内存，但我们想知道是否存在另一种更优雅、无额外开销的解决方案。

解答 #

首先明确：C++标准中没有任何机制可以“告知编译器某类数据竞争是可接受的”——数据竞争本身就是标准定义的UB触发条件，编译器不会提供绕过规则的接口，任何依赖“编译器忽略数据竞争”的做法都会导致程序行为不可预测。

1. 现有std::atomic方案的实际开销

你提到的std::atomic配合std::memory_order_relaxed的方案，其实已经是无额外运行时开销的最优选择：

• 在x86-64、ARMv8+等主流CPU架构上，relaxed内存序的原子加载/存储指令和普通非原子操作完全一致，没有额外的内存屏障或锁开销。
• 编译器层面的区别仅在于：原子变量会阻止编译器进行可能破坏内存可见性的优化（比如将变量缓存到寄存器不写回、重排操作顺序），而这正是TL2算法需要的——确保读取到的是内存中的实际值，后续版本检查能正确识别无效读取。

2. 其他“替代方案”的局限性

• volatile关键字：这是常见的误区。volatile仅阻止编译器优化变量的读写，但不提供任何线程间的内存可见性保证，也无法消除数据竞争导致的UB。TL2依赖版本检查作废无效读取，但volatile无法保证读操作能看到其他线程的写入（哪怕是部分写入），编译器依然可能生成违反语义的代码。
• 编译器扩展（如GCC的no_sanitize("thread")）：这类扩展仅关闭线程 sanitizer 的检测，并没有真正消除UB。编译器仍会基于“程序无数据竞争”的假设进行优化，可能生成重排指令、优化读取等错误代码，运行时行为依然不可控。

3. 更灵活的语法优化：std::atomic_ref（C++20+）

如果觉得std::atomic数组的语法不够优雅，可以使用C++20引入的std::atomic_ref，它可以包装普通内存区域的单个元素，无需将整个区域声明为原子数组：

char* memory_region = new char[size];

// 访问内存元素时用atomic_ref包装
std::atomic_ref<char> elem_ref(memory_region[idx]);
char val = elem_ref.load(std::memory_order_relaxed);
elem_ref.store(new_val, std::memory_order_relaxed);

这种方式在语法上更灵活，尤其是当内存区域已存在、无法改为原子数组时，同样没有额外运行时开销。

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