OpenMP并行区域中的std::vector push_back会导致错误共享吗

Question

下面的示例代码是我的工作代码的简化版本。在这段代码中，只在调用std::vector::push_back的最后一行写入共享变量。

std::vector<struct FortyByteStruct> results;
#pragma omp parallel for num_threads(8)
for (int i = 0; i < 250; i++)
{
struct FortyByteStruct result = some_heavy_work(i);
#pragma omp critical
{
results.push_back(result);
}
}

我想知道这个push_back操作是否会导致错误共享，让我有机会通过消除它来进一步优化。在深入研究这个问题之前，我决定先做一些台架测试。

使用chrono，我分别测量了some_heavy_work()和关键部分的挂钟执行时间。后者的执行时间大约是前者的10^(-4)倍，所以我得出结论，无论是否涉及虚假共享，优化这一部分几乎没有任何好处。

无论如何，我仍然很好奇虚假分享是否是这里的一个问题。我是否必须查看std::vector的内部实现？任何启发都将不胜感激。(我在VS2015上)

Answer 1

考虑到FortyByteStruct可能小于缓存行(通常为64字节)，在写入结果数据时可能存在一些错误共享。然而，它几乎不会产生影响，因为它将被关键部分的成本所掩盖，也会被修改vector本身(而不是它的数据)的"真正"共享所掩盖。您不需要知道std::vector实现的细节，只需要知道它的数据在内存中是连续的，并且它的状态(指向数据/大小/容量的指针)在向量变量本身的内存中。当多个线程以不受保护的方式访问同一缓存线上的单独数据时，错误共享通常是一个问题。请记住，错误共享不会影响正确性，只会影响性能。

错误共享的一个稍微不同的例子是，当您有一个std::vector<std::vector<struct FortyByteStruct>>，并且每个线程执行一个未受保护的push_back时。我在这里详细解释了这一点。

在您的示例中，对于已知的向量总大小，最好的方法是在循环之前调整向量的大小，然后只指定results[i] = result。这避免了关键部分，并且OpenMP通常以几乎没有错误共享的方式来分配循环迭代。此外，还得到了results的一个确定性阶。

也就是说，当你通过测量确认时间由some_heavy_work支配时，你就没事了。

Answer 2

我不是std:：vector实现方面的专家，但我确信它不会检查另一个进程是否同时在写。

尽管如此，这里有两条建议：

• 是的，关键操作的开销很小，但与并行执行"some_heavy_work"的增益相比可以忽略不计(我想…)。因此，毫无疑问，我会将其保留在中

• 您应该检查关键和原子之间的区别(openMP，原子与关键？)。

希望它能帮助