挥发性VS VolatileRead /写？ [英] Volatile vs VolatileRead/Write?

问题描述

我找不到的的VolatileRead /写（试行...），但仍任的例子：

在的我应该用挥发性 VS VolatileRead ？

When should I use volatile vs VolatileRead?

AFAIK的全部目的挥发性是创建的一半的围栏这样：

AFAIK the whole purpose of volatile is to create half fences so:

• 有关的 READ 的操作，读/写（在其他线程），它来自当前运行后，会不会栅栏前通过。所以 - 我们读到的最新值

• For a READ operation, reads/writes (on other threads) which comes AFTER the current operation , won't pass before the fence. hence - we read the latest value.

问题1

那么，为什么我需要 volatileRead ？似乎挥发性已做的工作。

So why do I need the volatileRead? it seems that volatile already do the work.

加 - 在C＃中的所有写操作是挥发性（不像说在Java中），无论你写一个挥发性或非挥发性场 - 因此我问：为什么我需要的 volatileWrite ？

Plus - in C# all writes are volatile (unlike say in Java), regardless of whether you write to a volatile or a non-volatile field - and so I ask: Why do I need the volatileWrite?

问题＃2

这是实施 VolatileRead ：

[MethodImpl(MethodImplOptions.NoInlining)]
public static int VolatileRead(ref int address)
{
    int num = address;
    MemoryBarrier();
    return num;
}

为什么要行 INT NUM =地址; 有没有？他们已经拥有的地址参数，它显然是持有价值。

Why the line int num = address; is there? they already have the address argument which is clearly holding the value.

推荐答案

您应该使用Thread.VolatileRead /写（）。这是一个设计错误在.NET 1.1，它采用了完全的内存屏障。这已得到纠正在.NET 2.0，但他们无法确定这些方法了，不得不增加一个新的方式来做到这一点，由System.Threading.Volatile类提供。这是一个类，抖动是知道的，它的替换的一个版本，这是适合于特定的处理器类型的方法中的JIT的时间。

You should never use Thread.VolatileRead/Write(). It was a design mistake in .NET 1.1, it uses a full memory barrier. This was corrected in .NET 2.0, but they couldn't fix these methods anymore and had to add a new way to do it, provided by the System.Threading.Volatile class. Which is a class that the jitter is aware of, it replaces the methods at jit time with a version that's suitable for the specific processor type.

在源$ C ​​$下作为可通过参考源的挥发性类的意见告诉的故事（编辑以适合）：

The comments in the source code for the Volatile class as available through the Reference Source tells the tale (edited to fit):

// Methods for accessing memory with volatile semantics.  These are preferred over 
// Thread.VolatileRead and Thread.VolatileWrite, as these are implemented more
// efficiently.
//
// (We cannot change the implementations of Thread.VolatileRead/VolatileWrite 
// without breaking code that relies on their overly-strong ordering guarantees.)
//
// The actual implementations of these methods are typically supplied by the VM at 
// JIT-time, because C# does not allow us to express a volatile read/write from/to 
// a byref arg. See getILIntrinsicImplementationForVolatile() in jitinterface.cpp.

是的，你很难找到它的用法示例。参考源是精心编写，测试和身经百战的C＃code，与线程处理兆字节一个很好的指南。的次数，它使用VolatileRead /写：零

坦率地说，.NET的内存型号是由CLR毫米和C＃毫米，就在最近的ARM内核添加新的规则作出相互矛盾的假设一个烂摊子。的的挥发性的关键字，这意味着不同的事情不同体系结构的一些证据的怪人语义。尽管这与内存模型弱的处理器通常可以假设一下C＃语言规范说是准确的。

Frankly, the .NET memory models are a mess with conflicting assumptions made by the CLR mm and C# mm with new rules added for ARM cores just recently. The weirdo semantics of the volatile keyword that means different things for different architectures is some evidence for that. Albeit that for a processor with a weak memory model you can typically assume that what the C# language spec says is accurate.

请注意，乔·达菲已经放弃了所有的希望并只是平了阻碍所有使用它。它是在普通的非常的不明智的假设，你可以做比语言和框架所提供的原语更好。挥发类的备注部分带来点回家：

Do note that Joe Duffy has given up all hope and just flat out discourages all use of it. It is in general very unwise to assume that you can do better than the primitives provided by the language and framework. The Remarks section of the Volatile class bring the point home:

在正常情况下，C＃的lock语句，在Visual Basic的SyncLock语句和Monitor类提供同步访问数据的最容易和最不容易出错的方式，而懒惰类提供写延迟初始化$的简单方法C $ C时不直接使用双重检查锁定。

Under normal circumstances, the C# lock statement, the Visual Basic SyncLock statement, and the Monitor class provide the easiest and least error-prone way of synchronizing access to data, and the Lazy class provides a simple way to write lazy initialization code without directly using double-checked locking.

这篇关于挥发性VS VolatileRead /写？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！