防止虚假分享的奇怪代码答案

【问题标题】：Strange code for preventing false sharing防止虚假分享的奇怪代码
【发布时间】：2017-01-17 12:52:01
【问题描述】：

我想从这个link讨论golang中的以下结构

// Local per-P Pool appendix.
    57  type poolLocal struct {
    58      private interface{}   // Can be used only by the respective P.
    59      shared  []interface{} // Can be used by any P.
    60      Mutex                 // Protects shared.
    61      pad     [128]byte     // Prevents false sharing.
    62  }

由于使用了 Mutex，上述结构一次只能访问一个线程。编码器将在线程开始时锁定结构，并在线程完成时将其解锁。所以内存不在线程之间共享。所以不会超过一个核心访问内存。因此，据我了解，虚假分享不会发生。如果不能发生虚假共享，编码器为什么要填充结构有额外的字节（填充[128]字节）？我的理解错了吗？

【问题讨论】：

是的，您的理解是错误的：“错误共享”与访问同一内存的多个线程无关（如果一个写入，则为竞争条件），但与处理器缓存行有关：只需 google 即可获得“错误共享” ：
@Volker Thabk 你。我明白了。让我澄清一下。假设有两个线程 t1 和 t2 在核心 C1 和 C2 上运行。让 t1 先运行（现在 t2 等待，因为有静音锁）。让 t1 将数据写入 c1 的 L1 缓存（存储我们的结构的缓存行）。现在 t2 在 C2 中准备就绪。但是 C2 中的 L2 缓存必须（通过 MESI 协议）更新为新值。在此之后，t2 可以继续其工作。这就是发生错误共享的地方。我说的对吗？
当您进行填充时，每个线程将在 L1 中分配一个缓存行，该缓存行将指向 L2 或更高内存中的不同内存位置。由于每个线程都在不同的内存位置上工作，因此它们不共享，因此没有 MESI 和错误共享。我说的对吗？
“过早的优化是万恶之源。” - Tony Hoare 爵士的名言（由 Donald Knuth 推广）。从中学习。并停止优化缓存行，除非您有完美的代码并衡量这是您当前的 #1 性能瓶颈。

标签： multithreading go mutex false-sharing

【解决方案1】：

同一缓存行上的内存位置会受到错误共享，这对性能非常不利。缓存行大小范围为 32 到 128 字节，具体取决于处理器型号。 128 字节填充将减少不同进程使用相同缓存行的机会，从而提高性能

在我看来，以下会更好，因为它会更明确

type poolLocal struct {
      _     [64]byte     // Prevents false sharing.
      private interface{}   // Can be used only by the respective P.
      shared  []interface{} // Can be used by any P.
      Mutex                 // Protects shared.
      _     [64]byte     // Prevents false sharing.
}

【讨论】：

哎呀。我不明白这是我问题的答案。我的问题是，如果只有一个线程可以访问内存，则不会发生错误共享，那么为什么程序员添加了额外的位。我现在自己清除了（看看我的 cmets 问题）。目的是使结构的大小成为缓存行的倍数。为什么在开始和/或结束时填充它会很重要？
此外，根据此链接：geeksforgeeks.org/… 编译器似乎更改了声明的变量的顺序。因此，您的填充样式与已发布的填充样式没有区别
@user3219492 false-sharing 与访问同一内存的线程无关。由于两个进程共享相同的cache line，您可能会将其视为性能问题
是的。我的疑问得到了解决（有问题的cmets）。我的意思是，您发布的内容并不是我所怀疑的答案。
@user3219492 编译器更改顺序是特定于语言的，即使 ANCI-C 也没有具体说明它是如何做到的。我经常看到人们在 golang 中以这种方式使用填充