64位结构上长的读/换

Question

Interlocked.Read(ref long)是否在64位架构上进行了“优化”？也就是说，如果我正在编写一个可供两种体系结构使用的库，是否应该关注在64位CPU上不必要地使用Interlocked.Read对性能的影响？

我想使用这样的东西，所以我想知道这是否有意义：

    // X64 is a preprocessor constant set for x64 builds  

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static long Read(ref long address)
    {
#if X64
        // atomic on 64-bit processors
        return address;
#else
        // if I got it right, this creates a full memory barrier
        return Interlocked.Read(ref address);
#endif
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void Write(ref long address, long value)
    {
#if X64
        // atomic on 64-bit processors
        address = value;
#else
        // if I got it right, this creates a full memory barrier
        Interlocked.Exchange(ref address, value);
#endif
    }

Answer 1

是的，您不必要地关注Interlocked的性能影响，因为Interlocked不仅对值执行原子操作，而且还确保该值对所有线程都是可见的(顺序一致性)。让我解释一下。在某些体系结构(包括一些64位架构)上，可以缓存写入内存位置的值以提高性能。简单地读取一个值可能不会读取由另一个线程编写的“最新”值，尽管它是一个原子操作。Interlocked还执行内存隔离，以便在栅栏之前的任何操作都将缓存的值刷新到实际内存中。因此，虽然您可能提高性能微乎其微，但您也引入了潜在的竞争条件。在这不是问题的体系结构上，Interlocked不会执行额外的工作，而是为您进行优化。

不幸的是，Interlocked的文档仍然不能完全满足这些细节。有关涉及Interlocked操作的围栏的更多细节，请参见Interlocked。

Answer 2

我只能回答第二个问题--你不应该关心它。您所能做的就是确定是否需要线程安全并相应地对变量进行读写。C#是一种抽象--您是为语言而编写的，而不是处理器。编译器和.NET框架担心处理器。

64位读取保证在64位处理器上是原子的，但正如您所说的，您正在为这两种体系结构编写。如果锁定成本是在64位架构上可以避免的一个重大障碍，那么在32位架构上，这个障碍将是一个尚未解决的问题。

有一个与锁定相关的成本，但更大的成本将来自不可预测的行为，而这些行为将来自于不为线程安全编写代码。