c++ - "pseudo-atomic"C++ 操作

Question

所以我知道在 C++ 中没有什么是原子的。但我试图弄清楚是否有任何我可以做出的“伪原子”假设。原因是我想避免在一些我只需要非常弱的保证的简单情况下使用互斥锁。

1) 假设我已经全局定义了 volatile bool b，它
最初我设置为true。然后我启动一个执行循环的线程

while(b) doSomething();

同时，在另一个线程中，我执行 b=true。

我可以假设第一个线程会继续执行吗？换句话说，如果 b 开始时为真，并且第一个线程在第二个线程分配 b=true 的同时检查 b 的值，我是否可以假设第一个线程将 b 的值读取为真？或者是否有可能在赋值 b=true 的某个中间点，b 的值可能被读取为 false？

2) 现在假设 b 最初是假的。然后第一个线程执行

bool b1=b;
bool b2=b;
if(b1 && !b2) bad();

而第二个线程执行 b=true。我可以假设 bad() 永远不会被调用吗？

3) int 或其他内置类型怎么样:假设我有 volatile int i，它最初是(比如说)7，然后我分配 i=7。我是否可以假设，在此操作期间的任何时间，来自任何线程的 i 的值都将等于 7？

4) 我有 volatile int i=7，然后我从某个线程执行 i++，所有其他线程只读取 i 的值。我可以假设我在任何线程中都没有任何值(value)，除了 7 或 8 吗？

5) 我有 volatile int i，从一个线程执行 i=7，从另一个线程执行 i=8。之后，我是否保证是 7 或 8(或我选择分配的任何两个值)？

Answer 1

标准C++中没有线程，而且Threads cannot be implemented as a library .

因此，该标准对使用线程的程序的行为没有任何说明。您必须查看线程实现提供的任何额外保证。

也就是说，在我使用的线程实现中:

(1) 是的，您可以假设不相关的值不会写入变量。否则整个内存模型就会消失。但是请注意，当您说“另一个线程”时，永远不要设置 b为假，这意味着任何地方，永远。如果是这样，该写入可能会在您的循环期间重新排序。

(2) 否，编译器可以对 b1 和 b2 的赋值重新排序，因此 b1 可能最终为真，而 b2 为假。在这种简单的情况下，我不知道为什么会重新排序，但在更复杂的情况下，可能有很好的理由。

[编辑:哎呀，当我回答 (2) 时，我忘记了 b 是不稳定的。从 volatile 变量读取不会被重新排序，抱歉，所以在典型的线程实现上是的(如果有任何这样的事情)，你可以假设你不会以 b1 true 和 b2 false 结束。]

(3) 同 1。volatile通常与线程无关。然而，它在某些实现(Windows)中非常令人兴奋，并且实际上可能意味着内存障碍。

(4) 在一个架构上int写入是原子的，虽然 volatile与它无关。另见...

(5) 仔细检查文档。可能是的，而且 volatile 是无关紧要的，因为在几乎所有架构上 int写入是原子的。但如果 int write 不是原子的，那么没有(对于上一个问题也没有)，即使它是 volatile 原则上你也可以获得不同的值。然而，鉴于这些值 7 和 8，我们正在谈论一个非常奇怪的架构，用于包含要在两个阶段写入的相关位的字节，但使用不同的值，您可能更可能获得部分写入。

举一个更合理的例子，假设出于某种奇怪的原因，您在一个只有 8 位写入是原子的平台上有一个 16 位 int。奇怪，但合法，因为 int必须至少为 16 位，您可以看到它是如何产生的。进一步假设您的初始值为 255。那么增量可以合法地实现为:

读取旧值

在寄存器中递增

写入结果的最高有效字节

写入结果的最低有效字节。

在第三步和第四步之间中断递增线程的只读线程可能会看到值 511。如果写入顺序不同，则可能会看到 0。

如果一个线程正在写入 255，另一个线程正在同时写入 256，并且写入被交错，则可能会永久留下不一致的值。在许多架构上不可能，但要知道这不会发生，您至少需要了解有关架构的一些信息。 C++ 标准中没有禁止它，因为 C++ 标准谈论执行被信号中断，但除此之外没有执行被程序的另一部分中断的概念，也没有并发执行的概念。这就是线程不仅仅是另一个库的原因——添加线程从根本上改变了 C++ 执行模型。它需要实现以不同的方式做事，因为您最终会发现例如您是否在 gcc 下使用线程而忘记指定 -pthreads .

同样的情况也可能发生在对齐 int 的平台上。写入是原子的，但未对齐 int写入是允许的，而不是原子的。例如 x86 上的 IIRC，未对齐 int如果写入跨越缓存线边界，则不能保证写入是原子的。 x86 编译器不会错对齐声明的 int变量，出于这个原因和其他原因。但是如果你玩结构包装的游戏，你可能会引发一个例子。

所以:几乎任何实现都会为您提供所需的保证，但可能会以相当复杂的方式实现。

总的来说，我发现为了避免互斥体，尝试依赖平台特定的关于内存访问的保证是不值得的，我不完全理解。使用互斥锁，如果速度太慢，请使用由真正了解体系结构和编译器的人编写的高质量无锁结构(或为其实现设计)。它可能是正确的，并且在正确的情况下可能会胜过我自己发明的任何东西。