假设我想使用一个 bool 状态标志来实现线程间的协作取消。 (我意识到应该最好使用 CancellationTokenSource 代替；这不是这个问题的重点。)

private volatile bool _stopping;

public void Start()
{
    var thread = new Thread(() =>
    {
        while (!_stopping)
        {
            // Do computation lasting around 10 seconds.
        }
    });

    thread.Start();
}

public void Stop()
{
    _stopping = true;
}

问题:如果我在另一个线程上在 0 秒调用 Start() 并在 3 秒调用 Stop()，循环是否保证在当前迭代结束时大约 10 秒退出？

我看到的绝大多数资料表明上述内容应该按预期工作；看: MSDN ; Jon Skeet ; Brian Gideon ; Marc Gravell ; Remus Rusanu 。

但是，volatile 只在读取时生成一个获取栅栏，在写入时生成一个释放栅栏:

A volatile read has “acquire semantics”; that is, it is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence. A volatile write has “release semantics”; that is, it is guaranteed to happen after any memory references prior to the write instruction in the instruction sequence. (C# Specification)

因此，不能保证 volatile 写入和 volatile 读取不会(看起来)被交换，如 Joseph Albahari 所观察到的那样。因此，后台线程可能会在当前迭代结束后继续读取 _stopping(即 false)的陈旧值。具体来说，如果我在 0 秒时调用 Start()，在 3 秒时调用 Stop()，后台任务可能不会按预期在 10 秒终止，而是在 20 秒或 30 秒终止，或者根本不会终止。

基于 acquire and release semantics ，这里有两个问题。首先，volatile 读取将被限制为从内存中刷新字段(抽象地说)，不是在当前迭代结束时，而是在后续 迭代结束时，因为获取栅栏发生 < em="">after 阅读本身。其次，更关键的是，没有任何东西可以强制 volatile 写入将值提交到内存，因此根本无法保证循环会终止。

考虑以下序列流:

Time   |     Thread 1                     |     Thread 2
       |                                  |
 0     |     Start() called:              |        read value of _stopping
       |                                  | <----- acquire-fence ------------
 1     |                                  |     
 2     |                                  |             
 3     |     Stop() called:               |             ↑
       | ------ release-fence ----------> |             ↑
       |        set _stopping to true     |             ↑
 4     |             ↓                    |             ↑
 5     |             ↓                    |             ↑
 6     |             ↓                    |             ↑
 7     |             ↓                    |             ↑
 8     |             ↓                    |             ↑
 9     |             ↓                    |             ↑
 10    |             ↓                    |        read value of _stopping
       |             ↓                    | <----- acquire-fence ------------
 11    |             ↓                    |    
 12    |             ↓                    |             
 13    |             ↓                    |             ↑
 14    |             ↓                    |             ↑
 15    |             ↓                    |             ↑
 16    |             ↓                    |             ↑
 17    |             ↓                    |             ↑
 18    |             ↓                    |             ↑
 19    |             ↓                    |             ↑
 20    |                                  |        read value of _stopping
       |                                  | <----- acquire-fence ------------

最重要的部分是内存栅栏，标记为 --> 和 <-- ，代表线程同步点。 _stopping 的 volatile 读取最多只能(似乎)向上移动到其线程的先前获取栅栏。但是，volatile 写入可以(似乎)无限期地向下移动，因为在它的线程上没有其他释放栅栏跟随它。换句话说，在对 _stopping 的写入和它的任何读取之间没有“synchronizes-with”(“先于发生”，“可见”)关系。

附言我知道 MSDN 对 volatile 关键字提供了非常有力的保证。但是，专家一致认为 MSDN 是错误的(并且没有得到 ECMA 规范的支持):

The MSDN documentation states that use of the volatile keyword “ensures that the most up-to-date value is present in the field at all times”. This is incorrect, since as we’ve seen [in the previous example], a write followed by a read can be reordered. (Joseph Albahari)

最佳答案

If I call Start() at 0s and Stop() at 3s on another thread, is the loop guaranteed to exit at the end of the current iteration at around 10s?

是的，7 秒绝对足以让一个线程感知到 _stopping 变量的变化。

近乎正式的解释

对于提供任何类型的可见性障碍(内存顺序)的每个变量，任何语言的规范都应提供以下保证:

Any change of the variable (with special memory order) from one thread will be observed in other threads during finit and bounded period of time.

没有这个保证，即使是变量的内存顺序特征也是无用的。

C# 规范明确提供了关于volatile 变量的保证，但我找不到相应的文本。

请注意，这种关于有限时间的保证与内存顺序保证(“获取”、“释放”等)无关，并且不能从障碍的定义中推断 和内存顺序。

正式-非正式的解释

什么时候说

I call Stop() at 3s

一个暗示，有一些可见的效果(例如，信息打印到终端)，这允许他声称大约 3 秒的时间戳(因为打印语句已在之后发出em> Stop()).

随着 C# 规范的优雅发挥(“10.10 执行顺序”):

Execution shall proceed such that the side effects of each executing thread are preserved at critical execution points. A side effect is defined as a read or write of a volatile field, a write to a non-volatile variable, a write to an external resource, and the throwing of an exception. The critical execution points at which the order of these side effects shall be preserved are references to volatile fields (§17.4.3), lock statements (§15.12), and thread creation and termination.

假设打印是一个关键执行点(可能它使用了锁)，您可能有信心目前将_stopping volatile 变量赋值作为端effect 对检查给定变量的另一个线程可见。

非正式解释

虽然允许编译器在代码中向前移动volatile变量的赋值，但它不能无限期地这样做:

• 不能在函数调用之后移动赋值，因为编译器不能对函数体做任何假设。

• 如果在一个循环内进行赋值，则应在下一个循环的另一个赋值之前完成。

• 虽然可以想象具有 1000 个连续简单赋值(对其他变量)的代码，因此 volatile 赋值可以延迟 1000 条指令，但编译器确实会执行此类延迟。即使是这样，在现代 CPU 上执行 1000 条简单指令也不会超过几微秒。

从 CPU 的角度来看，情况更简单:没有 CPU 会延迟对内存单元的分配超过有限数量的指令。

总的来说，volatile 变量的赋值只能在非常有限的指令数上延迟。

关于c# - 流行的 "volatile polled flag"模式坏了吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44121866/