c# - AutoResetEvent 与 bool 值停止线程

Question

我在工作线程中有一个对象，我可以指示它停止运行。我可以使用 bool 或 AutoResetEvent 来实现:

bool 值:

private volatile bool _isRunning;

public void Run() {
    while (_isRunning)
    {
        doWork();
        Thread.Sleep(1000);
    }
}

自动重置事件:

private AutoResetEvent _stop;

public void Run() {
    do {
        doWork();
    } while (!_stop.WaitOne(1000));
}

然后 Stop() 方法会将 _isRunning 设置为 false，或调用 _stop.Set()。

除了 AutoResetEvent 的解决方案可能会停止得更快一点，这些方法之间有什么区别吗？一个比另一个“更好”吗？

Answer 1

C# volatile 不提供所有保证。它可能仍然读取过时的数据。最好使用底层操作系统同步机制，因为它提供了更强大的保证。

所有这一切都非常深入 discussed作者 Eric Lippert(非常值得一读)，这里是简短的引用:

In C#, "volatile" means not only "make sure that the compiler and the jitter do not perform any code reordering or register caching optimizations on this variable". It also means "tell the processors to do whatever it is they need to do to ensure that I am reading the latest value, even if that means halting other processors and making them synchronize main memory with their caches".

Actually, that last bit is a lie. The true semantics of volatile reads and writes are considerably more complex than I've outlined here; in fact they do not actually guarantee that every processor stops what it is doing and updates caches to/from main memory. Rather, they provide weaker guarantees about how memory accesses before and after reads and writes may be observed to be ordered with respect to each other. Certain operations such as creating a new thread, entering a lock, or using one of the Interlocked family of methods introduce stronger guarantees about observation of ordering. If you want more details, read sections 3.10 and 10.5.3 of the C# 4.0 specification.

Frankly, I discourage you from ever making a volatile field. Volatile fields are a sign that you are doing something downright crazy: you're attempting to read and write the same value on two different threads without putting a lock in place. Locks guarantee that memory read or modified inside the lock is observed to be consistent, locks guarantee that only one thread accesses a given hunk of memory at a time, and so on.