c - 双核 x86 可以处理字节级并发访问(？)还有谁？

Question

我编写了以下代码，由多个进程并行执行:

// spawn 10 times with id=0..9 by a master process.
void slave_processing(int id)
{
  SHARED_TYPE last=id;
   for(;;) {
     /* each slave operates on a specific byte of the shared array. */
     if (shared[id]!=last) fprintf(stderr,"S%i expected %i\n",id,last);
     shared[id]+=id;
     last+=id;
     if (last>10*id) {last=0; shared[id]=0;}
   }
}

它们都使用相同的(IPC/linux)共享内存，但每个都访问数组的单独条目。它在我的双核机器上完美运行 SHARED_TYPE是 int和char 。我使用积极优化 (-O3) 进行编译，并检查了汇编的二进制文件以确认对 shared[id] 执行了内存引用。访问和寄存器用于 last .

但是，我很困惑。我预计在某个时刻，影响一个核心的字节可能不会反射(reflect)在另一个核心的缓存内容上。例如。一个核心可能在缓存中有 [xxyyzzuu] 并将 [xxyyZZuu] 写回内存，同时另一个核心已将内存字升级为 [XXyyzzuu](假设每对字符是我的 32 位字中的一个字节)。

linux 是否做了一些神奇的设置，以便通过 shmget 获得内存无法缓存？或者是否正在进行一些低级缓存同步，以确保核心 #1 可以读取核心 #2 的最新修改以更新所选字节，而不会产生令人讨厌的副作用？

您知道是否存在任何其他(多核)架构，上面的代码会失败(输入 fprintf)？

Answer 1

代码假设编译器不会缓存(例如，将内存中的内容一次读入寄存器并继续使用寄存器而不是内存)它在循环中干预的任何值，但会为每个值进行内存提取从共享段中读取。为了确保所有部分都能看到写入内存的数据，访问共享数组应该通过内存屏障来完成。

虽然依赖于编译器，但如果您的共享是 volatile 的，它通常会执行内存获取。

由于您调用 fprintf()，编译器必须假设 fprintf() 可以访问或更新 shared 数组中的某些内容 - 毕竟，编译器不知道 fprintf() 的作用，因此理论上它可以访问全局数组，编译器需要从共享重新获取该内存(除非它可以证明 fprintf 不可能更新它)

如果 shared 不是 volatile 的，并且您例如，您的代码可能会有不同的行为做

SHARED_TYPE last=id;
int wrong = 0,i;
for(i = 0; i < 10000000;i++) {
  if (shared[id]!=last) wrong++;
  shared[id]+=id;
  last+=id;
  if (last>10*id) {last=0; shared[id]=0;}
}
return wrong;

编译器不需要在每次迭代时执行内存获取来获取 shared[id] 的最新值。话又说回来，如果编译器确实缓存了一个值，它可能只是旋转循环，一次又一次地检查相同的正确内容，而不会从内存中获取更新的值，从而按预期留下 wrong = 0 。无论您在这里做什么都不安全，并且取决于编译器将为您生成什么代码 - 对于小的代码更改，它可能会生成具有显着不同结果的代码。

与此相关的是可以从内存中原子读取哪些数据类型，这取决于处理器、数据类型以及访问是否是内存对齐的。

这是对缓存一致性的补充。我们使用的常见桌面和服务器平台是缓存一致的，这意味着硬件负责更新内存，因此所有处理器/核心都可以看到更改，而不是例如。当另一个核心需要访问同一内存位置时，仅驻留在 1 个核心上的 L1 缓存中。 (某些内存区域，例如用于 DMA 的区域可能无法为您提供此类缓存一致性保证)

当今的桌面/服务器平台看起来非常像 NUMA，但许多更大、更特殊的构建 NUMA 系统没有缓存一致性保证。