Visual C 上的易失性变量和原子操作x86

Question

普通加载在 x86 上具有获取语义，普通存储具有释放语义，但是编译器仍然可以对指令重新排序。虽然栅栏和锁定指令（锁定的 xchg、锁定的 cmpxchg）会阻止硬件和编译器重新排序，但仍然需要使用编译器屏障来保护普通加载和存储。 Visual C++ 提供了 _ReadWriterBarrier() 函数，可以防止编译器重新排序，出于同样的原因，C++ 也提供了 volatile 关键字。我写下所有这些信息只是为了确保一切正确无误。所以上面写的都是正确的，是否有任何理由将其标记为将在受 _ReadWriteBarrier() 保护的函数中使用的易失性变量？

例如：

int load(int& var)
{
    _ReadWriteBarrier();
    T value = var;
    _ReadWriteBarrier();
    return value;
}

使该变量成为非易失性是否安全？据我了解，因为函数是受保护的，编译器内部无法进行重新排序。另一方面，Visual C++ 为易失性变量提供了特殊行为（与标准所做的不同），它使易失性读取和写入原子加载和存储，但我的目标是 x86，普通加载和存储在 x86 上应该是原子的无论如何，对吧？

提前致谢。

Answer 1

C 语言中也提供了 volatile 关键字。 “易失性”经常在嵌入式系统中使用，特别是当变量的值可能随时更改时（代码不采取任何操作）三种常见情况包括从内存映射的外设寄存器读取或由全局变量修改的全局变量。中断服务程序或多线程程序中的中断服务程序。

因此，这是最后一个可以将 volatile 视为与 _ReadWriteBarrier 类似的场景。

_ReadWriteBarrier 不是函数 - _ReadWriteBarrier 不会插入任何附加指令，并且不会阻止 CPU 重新排列读取和写入 — 它只会阻止编译器重新排列它们。 _ReadWriteBarrier 是为了防止编译器重新排序。

MemoryBarrier是为了防止CPU重排序！

编译器通常会重新排列指令...C++ 不包含对多线程程序的内置支持，因此编译器在重新排列代码时假定代码是单线程的。对于 MSVC，在代码中使用 _ReadWriteBarrier，这样编译器就不会跨它进行读写操作。

检查此链接以获取有关这些主题的更详细讨论
http://msdn.microsoft.com/en- us/library/ee418650(v=vs.85).aspx

关于您的代码片段 - 您不必使用 ReadWriteBarrier 作为 SYNC 原语 - 第一次调用 _ReadWriteBarrier 是不必要的。

使用 ReadWriteBarrier 时，您不必使用 volatile

您写道“它使 volatile 读取和写入原子加载和存储” - 我认为这样说是不行的，原子性和波动性是不同的。原子操作被认为是不可分割的 - ... http://www.yoda。 arachsys.com/csharp/threads/volatility.shtml

Answer 2

注：我不是这个话题的专家，我的一些说法是“我在互联网上听到的”，但我想我仍然可以澄清一些误解。

[编辑] 一般来说，我只会在由 #ifdef 检查保护的隔离的本地优化中依赖特定于平台的特性，例如 x86 原子读取和缺乏 OOOX目标平台，最好在 #else 路径中附带一个可移植的解决方案。

需要注意的事项

• 读/写操作的原子性
• 由于编译器优化而重新排序（这包括由于简单的寄存器缓存而被另一个线程看到的不同顺序）
• CPU 中的乱序执行

可能的误解

1. 据我了解，因为函数是受保护的，内部编译器无法进行重新排序。
[编辑]澄清一下：_ReadWriteBarrier提供了针对指令重新排序的保护，但是，您必须超越该函数的范围。 _ReadWriteBarrier 已在 VS 2010 中修复以实现此目的，早期版本可能会被破坏（取决于它们实际执行的优化）。

优化不仅限于功能。有多种机制（自动内联、链接时代码生成）跨越函数甚至编译单元（并且可以提供比小范围寄存器缓存更重要的优化）。

2. Visual C++ [...] 使易失性读取和写入原子加载和存储，
你在哪里找到的？ MSDN 表示，超出标准，将在读写周围设置内存屏障，不保证原子读取。

[编辑] 请注意，C#、Java、Delphi 等具有不同的内存 mdoels，并且可能会做出不同的保证。

3. 普通加载和存储在 x86 上应该是原子的，对吧？
不，他们不是。未对齐的读取不是原子的。如果它们对齐良好，它们恰好是原子的 - 我不会依赖这一事实，除非它是孤立的并且易于交换。否则你的“x86 的简化”就会成为该目标的锁定。

[编辑] 发生未对齐读取：

char * c = new char[sizeof(int)+1];
load(*(int *)c);      // allowed by standard to be unaligned
load(*(int *)(c+1));  // unaligned with most allocators

#pragma pack(push,1)
struct 
{
   char c;
   int  i;
} foo;
load(foo.i);         // caller said so
#pragma pack(pop)

如果您记得参数必须对齐并且您控制所有代码，那么这当然是所有学术内容。我不会再写这样的代码了，因为我经常被过去的懒惰所困扰。

4. 普通加载在 x86 上具有获取语义，普通存储具有释放语义
不。x86 处理器不使用乱序执行（或者更确切地说，没有可见的 OOOX - 我认为），但这并不能阻止优化器重新排序指令。

5. _ReadBarrier / _WriteBarrier / _ReadWriteBarrier 完成所有魔法
它们不会——它们只是阻止优化器重新排序。 MSDN 最终将其设为严重警告 对于 VS2010，但该信息显然适用于 previous版本也是如此。

---

现在，回答你的问题。

我假设该代码片段的目的是传递任何变量 N，并加载它（原子方式？）。最直接的选择是互锁读取或（在 Visual C++ 2005 及更高版本上）易失性读取。

否则，在读取之前，您需要为编译器和 CPU 设置屏障，在 VC++ 客厅中，这将是：

int load(int& var)
{   
  // force Optimizer to complete all memory writes:
  // (Note that this had issues before VC++ 2010)
   _WriteBarrier();    

  // force CPU to settle all pending read/writes, and not to start new ones:
   MemoryBarrier();

   // now, read.
   int value = var;    
   return value;
}

Noe that _WriteBarrier 在 MSDN 中有第二个警告：
*在过去版本的 Visual C++ 编译器中，_ReadWriteBarrier 和 _WriteBarrier 函数仅在本地强制执行，不会影响调用树上的函数。这些函数现在在调用树中一直强制执行。*

---

我希望这是正确的。 stackoverflowers，如果我错了，请纠正我。