指向堆栈变量的指针应该是易失的吗？

Question

我知道我应该使用volatile 关键字来告诉编译器不要优化对变量的内存读写。我也知道在大多数情况下它是should only be used to talk to non-C++ memory。

但是，我想知道在持有指向某个本地（堆栈）变量的指针时是否必须使用volatile。

例如：

//global or member variable
/* volatile? */bool* p_stop;

void worker()
{
    /* volatile? */ bool stop = false;
    p_stop = &stop;
    while(!stop)
    {
        //Do some work
        //No usage of "stop" or p_stop" here
    }
}

void stop_worker()
{
    *p_stop = true;
}

在我看来，具有某种优化级别的编译器可能会看到 stop 是一个局部变量，它永远不会更改，并且可以用 while(true) 替换 while(!stop)，从而在什么都不做的情况下更改 *p_stop。

那么，在这种情况下是否需要将指针标记为 volatile？

P.S：请不要告诉我为什么不使用它，使用此 hack 的真实代码是出于（复杂到难以解释的）原因。

编辑：

1. 我没有提到这两个函数在不同的线程上运行。 worker() 是第一个线程的函数，应该使用p_stop 指针从另一个线程停止。

2. 我不想知道有什么更好的方法来解决这种黑客行为背后的真正原因。我只是想知道这是否是 C++ 中定义的\未定义的行为（11），以及这是否依赖于编译器\平台\等。到目前为止，我看到@Puppy 说每个人都错了，而且这是错误的，但没有参考表明这一点的特定标准。

我知道你们中的一些人对“不要教训我”部分感到冒犯，但请坚持真正的问题 - 我应该使用 volatile 还是不使用？或者这是UB？如果可以，请通过提供完整的答案帮助我（和其他人）学习新知识。

Answer 1

我只是想知道这是否是 C++ 中已定义\未定义的行为（就此而言是 11 个）

Ta-da（来自N3337，“准C++11”）

如果其中一个修改了内存位置 [..] 而另一个访问或修改了相同的内存位置，则两个表达式求值会发生冲突。

§1.10/4

和：

如果程序的执行包含不同线程中的两个冲突操作，则该程序的执行包含数据竞争，其中至少一个不是原子的，并且两者都不会在另一个之前发生。任何此类数据竞争都会导致未定义的行为。 [..]

§1.10/21

您正在从不同的线程访问对象stop 的（内存位置），这两种访问都不是原子的，因此也没有“发生在之前”的关系。简而言之，您存在数据竞争，因此存在未定义的行为。

我不想知道有什么更好的方法来解决这种黑客行为背后的真正原因。

原子操作（由 C++ 标准定义）是唯一（可靠）解决此问题的方法。

Answer 2

那么，在这种情况下是否需要将指针标记为 volatile？

没有。这不是必需的，主要是因为 volatile 在这种情况下甚至无法远程覆盖您需要它执行的操作。您必须使用实际的同步原语，例如原子操作或互斥锁。在此处使用volatile 是未定义的行为，您的程序将爆炸。

volatile 对并发没有用处。它可能对实现并发原语有用，但还远远不够。

坦率地说，您是否想使用实际的同步原语是无关紧要的。如果你想编写正确的代码，你别无选择。

Answer 3

P.S：请不要告诉我为什么不使用它，

我不确定我们应该说什么。编译器管理堆栈，因此您对它所做的任何事情在技术上都是未定义的行为，并且在升级到编译器的下一个版本时可能无法正常工作。

您还做出了可能与编译器优化时的假设不同的假设。这是使用（或不使用）volatile 的真正原因；您为编译器提供指导，帮助它确定优化是否安全。使用volatile 告诉编译器它应该假设这些变量可能由于外部影响（其他线程或特殊硬件行为）而改变。

所以是的，在这种情况下，您似乎需要用 volatile 限定符标记 both p_stop 和 stop。

（注意：这是必要的但还不够，因为它不会导致在具有宽松内存模型的语言实现中发生适当的行为，该模型需要障碍来确保正确性。请参阅https://en.wikipedia.org/wiki/Memory_ordering#Runtime_memory_ordering）

Answer 4

从所提供的细节中根本无法回答这个问题。

正如问题中所述，这是一种完全不受支持的线程间通信方式。

所以唯一的答案是：

指定您正在使用的编译器版本，并希望有人知道其最黑暗的秘密或参考您的文档。所有的 C++ 标准都会告诉你这是行不通的，任何人都可以告诉你的是“可能工作但不工作”。

没有“哦，伙计们，大家都知道这很有效，我该怎么做作为解决方法？wink wink”的答案。

除非您的编译器不支持原子或适当的并发机制，否则没有正当理由这样做。 “不支持”不是“解释起来很复杂”，所以我会根据该代码片段着迷，以了解没有正确执行此操作的可能原因（除了古老的编译器）。