像我这样一个问题一直问的，但我是一个有点不同。现在的问题是，为什么volatile关键字不在 C＃允许在类型 System.Double 和 System.Int64 等？

在乍一看，我回答了我的同事，好了，在32位机器上，这些类型至少需要两年蜱甚至进入处理器和.NET框架有抽象出处理器的具体细节的意图像那样。对此他回应，这不是抽象什么，如果它是$ P $使用，因为一个特定处理器的问题的一个功能pventing你！

他暗示使用框架这样的摘要信息远离程序员特定处理器的细节应该不会出现一个人。因此，该框架（或C＃）应该抽象出来的​​，做它需要做的，提供相同的担保 System.Double 等。（是否是一个信号量，记忆障碍，或其他）。我认为，该框架不应该添加一个信号量的开销上挥发性，因为程序员不希望这样的开销，这样的关键字，因为一个信号量不所必需的32位的类型。对于64位类型的更大的负荷可能会作为一个惊喜，所以，为.NET Framework最好还是不答应，并让你做你自己的信号量上更大的类型，如果开销是可以接受的。

这导致我们的调查volatile关键字的全部意义所在。 （见此页）。该页面的状态在附注：

在C＃中，使用volatile修饰符的所有访问该字段使用VolatileRead或VolatileWrite现场的保证。

嗯..... VolatileRead 和 VolatileWrite 都支持我们的64位类型！我的问题，那么，是，

为什么volatile关键字不在 C＃允许在类型 System.Double 和 System.Int64 等？

不是一个真正的回答你的问题，但是...

我是pretty的确保你所引用的MSDN文档是不正确时，它说的使用volatile修饰符中的字段保证所有访问该字段使用VolatileRead或VolatileWrite。

直接读取或写入 挥发性 场只（读，当获取围栏释放栅栏写入时）产生一个半围栏。

借助 VolatileRead 和 VolatileWrite 方法使用的 MemoryBarrier 内部，生成一个完整的围栏。

乔·达菲知道一两件事有关并发编程; 这是他不得不说的挥发性：

（顺便说一句，很多人想知道   负荷和之间的差   变量的存储标记为挥发性   并呼吁Thread.VolatileRead和   Thread.VolatileWrite。区别   是，前者的API   比即时编译实施强   code：他​​们达到获取/释放   通过在发光全栅栏语义   右侧。这些API更   昂贵调用过，但至少   让你决定一个   调用点逐调用点根据这些   个人加载和存储需要的   MM担保。）

A question like mine has been asked, but mine is a bit different. The question is, "Why is the volatile keyword not allowed in C# on types System.Double and System.Int64, etc.?"

On first blush, I answered my colleague, "Well, on a 32-bit machine, those types take at least two ticks to even enter the processor, and the .Net framework has the intention of abstracting away processor-specific details like that." To which he responds, "It's not abstracting anything if it's preventing you from using a feature because of a processor-specific problem!"

He's implying that a processor-specific detail should not show up to a person using a framework that "abstracts" details like that away from the programmer. So, the framework (or C#) should abstract away those and do what it needs to do to offer the same guarantees for System.Double, etc. (whether that's a Semaphore, memory barrier, or whatever). I argued that the framework shouldn't add the overhead of a Semaphore on volatile, because the programmer isn't expecting such overhead with such a keyword, because a Semaphore isn't necessary for the 32-bit types. The greater overhead for the 64-bit types might come as a surprise, so, better for the .Net framework to just not allow it, and make you do your own Semaphore on larger types if the overhead is acceptable.

That led to our investigating what the volatile keyword is all about. (see this page). That page states, in the notes:

In C#, using the volatile modifier on a field guarantees that all access to that field uses VolatileRead or VolatileWrite.

Hmmm.....VolatileRead and VolatileWrite both support our 64-bit types!! My question, then, is,

"Why is the volatile keyword not allowed in C# on types System.Double and System.Int64, etc.?"

Not really an answer to your question, but...

I'm pretty sure that the MSDN documentation you've referenced is incorrect when it states that "using the volatile modifier on a field guarantees that all access to that field uses VolatileRead or VolatileWrite".

Directly reading or writing to a volatile field only generates a half-fence (an acquire-fence when reading and a release-fence when writing).

The VolatileRead and VolatileWrite methods use MemoryBarrier internally, which generates a full-fence.

Joe Duffy knows a thing or two about concurrent programming; this is what he has to say about volatile:

(As an aside, many people wonder about the difference between loads and stores of variables marked as volatile and calls to Thread.VolatileRead and Thread.VolatileWrite. The difference is that the former APIs are implemented stronger than the jitted code: they achieve acquire/release semantics by emitting full fences on the right side. The APIs are more expensive to call too, but at least allow you to decide on a callsite-by-callsite basis which individual loads and stores need the MM guarantees.)