use*_*183 5 c++ multithreading mutex atomic memory-fences
假设我们有一个内存区域,某个线程正在其中写入数据。然后它将注意力转向其他地方并允许任意其他线程读取数据。然而,在某个时间点,它想要重用该内存区域并再次写入。
编写器线程提供一个布尔标志(valid),它指示内存仍然可以有效读取(即,他还没有重用它)。在某些时候,他会将此标志设置为 false,并且永远不会再次将其设置为 true(它只会翻转一次,仅此而已)。
考虑到顺序一致性,对于作者和读者来说,分别使用这两个代码片段应该是正确的:
...
valid = false;
<write to shared memory>
...
Run Code Online (Sandbox Code Playgroud)
和
...
<read from shared memory>
if (valid) {
<be happy and work with data read>
} else {
<be sad and do something else>
}
...
Run Code Online (Sandbox Code Playgroud)
显然我们需要做一些事情来确保顺序一致性,即插入必要的获取和释放内存屏障。在将任何数据写入段之前,我们希望在写入线程中将该标志设置为 false 。我们希望在检查之前在读取器线程中从内存中读取数据valid。后者是因为我们知道 valid 是单调的,即如果之后它仍然有效则读时也是有效的。
在内存访问和访问之间插入一个完整的栅栏valid就可以了。然而,我想知道,制造valid一个原子是否就足够了?
std::atomic<bool> valid = true;
Run Code Online (Sandbox Code Playgroud)
然后
...
valid.store(false); // RELEASE
<write to shared memory>
...
Run Code Online (Sandbox Code Playgroud)
和
...
<read from shared memory>
if (valid.load()) { // ACQUIRE
<be happy and work with data read>
} else {
<be sad and do something else>
}
...
Run Code Online (Sandbox Code Playgroud)
看来在这种情况下,使用原子存储和读取所隐含的释放和获取操作对我不利。编写器中的 RELEASE 不会阻止内存访问向上移动(只是上面的代码可能不会向下移动)。同样,读取器中的 ACQUIRE 不会阻止内存访问向下移动(只是下面的代码可能不会向上移动)。
如果这是真的,为了使这个场景工作,我还需要在编写器线程中获取(即加载)并在读取器线程中使用释放(即存储)。或者,我可以只使用普通的布尔标志,并使用共享互斥体保护线程中的写入和读取访问(仅对它!)。通过这样做,我可以有效地在两个线程中同时拥有 ACQUIRE 和 RELEASE,从而将访问valid与内存访问分开。
因此,这与受 保护的atomic<bool>常规程序之间存在非常严重的差异,这是正确的吗?boolmutex
编辑:原子上的加载和存储实际上似乎有所不同。std::atomicC++11 的 分别用于两者memory_order_seq_cst(!),而不是memory_order_acquireandmemory_order_release分别用于加载和存储。
相反,tbb::atomic使用memory_semantics::acquireandmemory_semantics::release而不是memory_semantics::full_fence.
因此,如果我的理解是正确的,那么对于标准 C++11 原子,代码将是正确的,但对于 tbb 原子,则需要向memory_semantics::full_fence加载和存储添加显式模板参数。
写入器将valid标志切换为false并开始写入数据,而读取器可能仍在从中读取数据。
设计缺陷在于错误的假设:只要读取器在完成读取后检查数据有效性,读取和写入同一内存区域就不是问题。
C++ 标准将其称为数据竞争,它会导致未定义的行为。
正确的解决方案是使用std::shared_mutex管理对单个写入器和多个读取器的访问的方法。
| 归档时间: |
|
| 查看次数: |
3657 次 |
| 最近记录: |