问题标签 [false-sharing]

众所周知，使用 pad 使结构独占一个或多个缓存行对性能有好处。

但是对于什么场景，我们应该添加如下这样的pad来提高性能呢？
这里有一些经验法则吗？

大多数硬件上的cacheline大小是64字节。</p>

我不知道为什么@Contened 在字段或对象之前和之后填充 128 个字节？

我已经尝试阅读以下两篇文章来缓解我的困惑。</p>

• jvmls-July2013-竞争

悲观地处理启用相邻缓存行预取器的情况

• 邮件.openjdk

请注意，我们使用 128 字节，是大多数硬件上缓存行大小的两倍，以针对相邻扇区预取器进行调整，将错误共享冲突扩展到两个缓存行

他们都说使用 128 字节的原因是为了调整相邻扇区预取器，将错误共享冲突扩展到两个缓存行。</p>

但是启用相邻缓存行预取器的情况是什么？

环境：x86-64；linux-centos；8-cpu-core
为了测试“错误共享性能”，我编写了这样的 c++ 代码：

这是我的编译命令：g++ xxx.cpp --std=c++11 -O0 -lpthread -g 所以没有 opt(O0)

我打印 a、b、c、d 虚拟地址是

这是执行结果：

据我了解，thread3 与其他线程没有“缓存弹跳”或“错误共享”问题，那么为什么它比线程 4 慢？

另外：如果我更改int32_t a,b为int64_t a,b，结果将更改为：

这是我预测的

我正在尝试添加缓存行填充以避免错误共享问题，但我看不出加速有很大差异。使用填充，它的速度只有 1.2 倍。我正在运行没有填充的代码和带有填充 n = 7 亿次的代码进行测试。我应该获得超过 1.2 倍的加速吗？也许我的填充实现错过了一些东西？我要添加 15 个整数填充，因为我假设不必在缓存行的开头分配计数器。任何提示表示赞赏。

这是我的代码：

. . . . . . . . 我为我的并行代码和 DevCpp 程序和 OpenMP 使用 2 个线程。我的并行 OpenMP C 代码以与串行代码相同或慢得多的速度运行！有什么解决办法吗？

我在一个项目上使用 C++11，这是一个函数：

功能就是这样。您会看到有一个std::vector，它存储了线程的所有结果。

我的问题是：会std::vector导致虚假分享吗？如果可以，有什么方法可以避免在使用std::vector存储线程结果时出现错误共享？

目标：在java中测试虚假共享

问题：我在字段上添加了@Contended 注释，但类布局没有显示填充字节。虚假分享仍然发生。
我有 3 个测试：

1. 没有填充
2. 添加长变量作为填充字节
3. 使用@Contended 注解添加填充字节

环境：

• macos Monterey 12.1 MacBookPro m1 max
• OpenJDK 运行时环境 (Zulu 8.52.0.23-CA-macos-aarch64) (build 1.8.0_282-b08)

ps：我已经尝试添加-XX:-RestrictContended选项，但仍然无法正常工作。

这是我的测试代码：

输出：

嗨，我在测试代码中没有发生预期的错误共享时遇到问题。

我正在尝试创建一个进程唯一的线程管理器，它可以均匀地管理多个线程。

唯一的线程管理器类不是线程池，它通过将任务函数分配给指定的线程进行操作，并且能够获得任务函数的返回值，这不仅仅是将任务推入队列而不考虑。此外，线程管理器不关心任务的大小（计算量）。

线程管理器将被一个线程（主线程）用于处理计算部分，并且它会被非常频繁地使用。这样做的原因是，我的流程将具有游戏循环设计模式，并且我想让游戏循环超过 120 FPS，这意味着必须在 8.3 毫秒内完成 1 个游戏循环。一个线程（主线程）可能会在 1 个游戏循环内多次分配此任务，因此减少/消除上下文切换成本是我的主要关注点。我的结论是让线程管理器的线程自旋锁。

简而言之，游戏循环将按照两个步骤进行多次迭代。

1. 主循环将任务分配给线程管理器。
2. 等待线程管理器的任务结果。

下面是我的测试代码。

线程管理器.h

主文件

对于 Interlocked 系列函数、__forceinline、静态变量的脏声明等，我感到非常抱歉。

另一方面，我使用“long long”作为锁变量的原因是没有“bool”类型。我宁愿尝试“短”，但当我测量“短”和“长”之间的时间时，它没有显着差异。相反，“short”稍微慢了一点，我猜原因是在 64 位环境中使用了 16 位寄存器。此外，bool 或 short 类型可能会导致内存对齐问题。所以我使用了“long long”类型。

CThreadManager 之所以有私有构造函数，是为了明确禁止“new CThreadManager()”。

“reinterpret_cast”的使用被最小化。我认为它的成本是编译时间，但我从 stackoverflow 看到一个问题，它有运行时成本。我还不确定。所以只需在线程函数开始时使用它一次。

到目前为止，我已经通过更改检查了虚假共享现象

SData::ullData[8] -> SData::ullData 1

此外，使用 Sleep(0) 显着减少了 WaitForResult() 中线程时间片的浪费，并减少了线程内的总执行时间。

这段代码的结果显示

在我的环境中。

但是，我才意识到除了 SData::ullData 之外，还有另一个地方肯定会发生错误共享，即s_pThreadQuits、s_pTaskLocks、s_ppTasks、s_pTaskResults。

为什么这些变量不会发生错误共享？

[编辑]

我所说的“错误共享”是指“不同线程访问但共享相同缓存线的内存地址”是

1. SData g_stDataN（在每个 FunctionN() 中）
2. s_pThreadQuits、s_pTaskLocks、s_pTaskResults、s_ppTasks（在 Thread() 中）

我想到了 2. 变量也将加载到缓存中，就像 g_stDataN（在我的环境中为 64 字节）所做的那样。我将 SData 的大小设置为 64 字节，以实现“填充”方法的结果，以避免错误共享。

但是，就 s_pThreadQuits 的大小既不是 64 字节也不是填充的而言，它也应该具有错误共享。

就像下面这张图片。

图片来源来自 https://www.codeproject.com/Articles/85356/Avoiding-and-Identifying-False-Sharing-Among-Threa