c++ - 现实生活中是否存在简单的 bool 指针作为线程取消标志不会有效取消线程的情况？

Question

首先，我理解正式地，使用非 atomic 标志取消线程是非常未定义的行为，因为语言没有指定是否将写入此变量在线程退出之前。

在工作中，这是很久以前实现的，大多数计算线程在整个工作过程中检查此 bool 的值，以优雅地取消它们正在做的任何事情。当我第一次看到这个时，我的第一 react 是改变所有这些以使用更好的方法(在这种情况下，QThread::requestInterruption 和 QThread::interruptionRequested 看起来像一个可行的替代方案)。快速搜索代码发现整个代码库中大约有 800 次出现此变量/构造，所以我放弃了。

当我找到一位(资深，以多年经验而言)同事时，他向我保证，尽管这可能确实是错误的，但他从未见过它无法实现其目的。他认为，唯一会出错的情况是，如果允许一个(组)线程运行，而另一个实际更改此标志的线程在其他线程完成之前永远不会被允许执行。他还争辩说，在这种情况下，操作系统会进行干预并在所有线程之间公平地分配运行时，从而可能导致取消延迟。

现在我的问题是:在现实生活中(最好是在常规系统上，基于 x86/ARM，最好是 C 或 C++)是否确实会失败？

请注意，我并不是要赢得争论，因为我的同事认为这在技术上是不正确的，但我想知道它是否会导致问题以及在什么情况下可能会发生这种情况。

Answer 1

解决这个问题的最简单方法是将其简化为一个相当简单的示例。编译器将优化读取标志，因为它不是原子的并且被另一个线程写入是 UB；因此该标志永远不会被实际读取。

您同事的论点是基于这样的假设，即当您取消引用标志时，编译器实际上会加载该标志。但实际上它没有义务这样做。

#include <thread>
#include <iostream>

bool cancelled = false;
bool finished = false;

void thread1() {
    while(!cancelled) {
        std::cout << "Not cancelled";
    }
}
int main() {
    std::thread t(thread1);
    t.detach();
    cancelled = true;
    while(!finished) {}
}

要在 coliru 上运行，加载 http://coliru.stacked-crooked.com/a/5be139ee34bf0a80 ，您将需要编辑并进行微不足道的更改，因为对于不终止的片段，缓存会被破坏。

实际上，他只是在打赌编译器的优化器会做得很差，这似乎是一件非常糟糕的事情。