我一直在阅读Joe Duffy关于并发编程的书。我有一个关于无锁线程的学术问题。
第一：我知道无锁线程充满了危险（如果你不相信我，请阅读书中有关内存模型的部分）
不过，我有一个问题：
假设我有一个带有int属性的类。
多个线程将非常频繁地读取此属性引用的值
值很少会发生变化，当它发生变化时，它将是一个改变它的线程。
如果它确实发生变化，而另一个使用它的操作正在飞行中，那么任何人都不会失去一个手指（任何人使用它的第一件事就是将它复制到局部变量）
我可以使用锁（或readerwriterlockslim来保持读取并发）。
我可以标记变量volatile（很多例子都是这样做的）
然而，即使是不稳定也可能会带来性能损失。
如果我在更改时使用VolatileWrite，并使读取的访问正常，该怎么办？像这样的东西：
public class MyClass
{
private int _TheProperty;
internal int TheProperty
{
get { return _TheProperty; }
set { System.Threading.Thread.VolatileWrite(ref _TheProperty, value); }
}
}
我不认为我会在现实生活中尝试这一点，但我对答案感到好奇（最重要的是，作为我是否理解我一直在阅读的记忆模型的检查点）。
将变量标记为“volatile”有两个影响。
1）读取和写入具有获取和释放语义，因此对于该存储器位置的读取和写入，其他存储器位置的读取和写入将不会“及时向前和向后移动”。 （这是一个简化，但你明白我的意思。）
2）抖动生成的代码不会“缓存”逻辑上不变的值。
前一点是否与您的场景相关，我不知道;你只描述了一个内存位置。是否只有易失性写入而不是易失性读取是很重要的，由您决定。
但在我看来，后一点非常重要。如果您对非易失性变量进行自旋锁定：
while(this.prop == 0) {}
抖动是在生成此代码的权利范围内，就像您编写的那样
if (this.prop == 0) { while (true) {} }
不管它是否确实如此，我不知道，但它有权利。如果你想要的是代码实际上重新检查每个循环的属性，将它标记为volatile是正确的方法。
将变量标记为“volatile”有两个影响。
1）读取和写入具有获取和释放语义，因此对于该存储器位置的读取和写入，其他存储器位置的读取和写入将不会“及时向前和向后移动”。 （这是一个简化，但你明白我的意思。）
2）抖动生成的代码不会“缓存”逻辑上不变的值。
前一点是否与您的场景相关，我不知道;你只描述了一个内存位置。是否只有易失性写入而不是易失性读取是很重要的，由您决定。
但在我看来，后一点非常重要。如果您对非易失性变量进行自旋锁定：
while(this.prop == 0) {}
抖动是在生成此代码的权利范围内，就像您编写的那样
if (this.prop == 0) { while (true) {} }
不管它是否确实如此，我不知道，但它有权利。如果你想要的是代码实际上重新检查每个循环的属性，将它标记为volatile是正确的方法。
问题是阅读线程是否会 曾经 看到变化。这不仅仅是它是否看到它的问题 立即。
坦率地说，我已经放弃了试图理解波动性 - 我知道这并不意味着我曾经想过的......但我也知道，在阅读线上没有任何记忆障碍，你可能正在阅读永远相同的旧数据。
“性能打击” volatile 是因为编译器现在生成代码来实际检查值而不是优化它 - 换句话说，你会 有 无论你做什么，都要取得这种性能。
在CPU级别，是每个处理器都会 终于 看到内存地址的变化。即使没有锁或内存障碍。锁和障碍只会确保所有这些都发生在相对排序中（例如其他说明），以使其对您的程序来说是正确的。
问题不在于缓存一致性（我希望Joe Duffy的书没有犯这个错误）。缓存保持一致 - 只是这需要时间，并且处理器不愿意等待这种情况发生 - 除非你强制执行它。因此，处理器继续前进到下一条指令，该指令可能会或可能不会发生 之前 前一个（因为每个内存读/写make需要不同的时间。具有讽刺意味的是 因为 处理器同意一致性等的时间 - 这会导致一些高速缓存行比其他高速缓存更快（即取决于行是修改，独占，共享还是无效，它需要更多或更少的工作才能进入必要的国家）。）
因此，读取可能看起来很旧或来自过时的缓存，但实际上它只是比预期更早发生（通常是因为前瞻和分支预测）。当它真的 是 读取，缓存是连贯的，从那时起它刚刚发生了变化。因此，当你阅读它时，它的价值并不老，但现在你需要它的时候。你刚才读完了。 :-(
或者等效地，它的编写时间晚于您编写的代码逻辑。
或两者。
无论如何，如果这是C / C ++，即使没有锁/障碍，你也会 终于 获取更新的值。 （通常在几百个周期内，因为内存耗时很长）。在C / C ++中，您可以使用volatile（弱非线程volatile）来确保不从寄存器中读取值。 （现在有一个非连贯的缓存！即寄存器）
在C＃中，我不太了解CLR知道一个值可以在寄存器中保留多长时间，也不知道如何确保从内存中真正重新读取。你已经失去了'弱'的波动。
我怀疑只要变量访问没有完全被编译掉，你最终会用完寄存器（x86没有很多开始）并重新读取。
但我不能保证。如果你可以将你的volatile读取限制在你的代码中的某个特定点，这通常但不常见（即在一段时间（thing_to_do）循环中开始下一个任务）那么这可能是你能做的最好的。
这是我在“最后一个作家获胜”模式适用于该情况时使用的模式。我用过了 volatile 关键字，但在Jeffery Richter的代码示例中看到此模式后，我开始使用它。
对于正常事物（如内存映射设备），在CPU / CPU内部/之间进行的缓存一致性协议是为了确保共享该内存的不同线程获得一致的事物视图（即，如果我更改了它是一个CPU中的内存位置 将 被其缓存中有内存的其他CPU看到。在这方面，volatile将有助于确保优化器不会通过读取寄存器中缓存的值来优化内存访问（无论如何总是通过缓存）。 C＃文档似乎很清楚。同样，应用程序员通常不必自己处理缓存一致性。
我强烈建议您阅读免费提供的论文“每个程序员应该了解的内存”。引擎盖下有很多魔法可以阻止自己在脚下射击。
在C＃中， int type是线程安全的。
既然你说只有一个线程写入它，你就不应该争论什么是正确的值，只要你缓存一个本地副本，就不应该得到脏数据。
但是，您可以申报 挥发物 如果OS线程将进行更新。
还要记住一些 操作 不是 原子，如果你有多个作家，可能会导致问题。例如，即使 bool 如果你有多个作家，类型不会腐败，这样的声明：
a = !a;
不是原子的。如果两个线程同时读取，则表示存在竞争条件。