gpt4 book ai didi

c++ - atomic 与受互斥锁保护的 bool

转载 作者:塔克拉玛干 更新时间:2023-11-03 02:15:48 27 4
gpt4 key购买 nike

假设我们有一个内存区域,某个线程正在向其中写入数据。然后它将注意力转移到别处并允许任意其他线程读取数据。然而,在某个时间点,它想要重用该内存区域并再次写入。

写入器线程提供了一个 bool 标志 ( valid ),它表示内存仍然有效,可以从中读取(即他还没有重新使用它)。在某个时候,他会将此标志设置为 false,并且再也不会将其设置为 true(它只会翻转一次,就是这样)。

在顺序一致性的情况下,编写者和读者分别使用这两个代码片段应该是正确的:

...
valid = false;
<write to shared memory>
...

...
<read from shared memory>
if (valid) {
<be happy and work with data read>
} else {
<be sad and do something else>
}
...

我们显然需要做一些事情来确保顺序一致性,即插入必要的获取和释放内存屏障。我们希望在编写器线程中将标志设置为 false,将任何数据写入段之前。我们希望在读取器线程之前检查valid时从内存中读取数据.后者是因为我们知道有效是单调的,即,如果它在阅读后仍然有效,那么它在阅读时有效。

在内存访问和访问 valid 之间插入一个完整的栅栏会成功的。但是,我想知道是否制作 valid一个原子就够了吗?

std::atomic<bool> valid = true;

然后

...
valid.store(false); // RELEASE
<write to shared memory>
...

...
<read from shared memory>
if (valid.load()) { // ACQUIRE
<be happy and work with data read>
} else {
<be sad and do something else>
}
...

在这种情况下,使用原子存储和读取的隐含释放和获取操作似乎对我不利。编写器中的 RELEASE 不会阻止内存访问在它上面移动(只是上面的代码可能不会向下移动)。同样,阅读器中的 ACQUIRE 不会阻止内存访问在其上向下移动(只是来自下方的代码可能不会向上移动)。

如果这是真的,为了使这个场景起作用,我还需要在写入线程中进行 ACQUIRE(即加载),并在读取线程中进行 RELEASE(即存储)。或者,我可以只使用一个普通的 bool 标志,并在具有共享互斥锁的线程中保护写入和读取访问(仅对它!)。通过这样做,我将有效地在两个线程中同时拥有一个 ACQUIRE 和一个 RELEASE,将 valid 分开从内存访问访问。

所以这将是 atomic<bool> 之间非常严重的差异和一个普通的boolmutex 保护, 这是正确的吗?

编辑:实际上,加载和存储在原子上隐含的内容似乎有所不同。 std::atomic C++11 使用 memory_order_seq_cst对于两者 (!),而不是 memory_order_acquirememory_order_release分别用于加载和存储。

相比之下,tbb::atomic使用 memory_semantics::acquirememory_semantics::release而不是 memory_semantics::full_fence .

因此,如果我的理解是正确的,那么代码对于标准 C++11 原子是正确的,但是对于 tbb 原子,需要添加显式的 memory_semantics::full_fence。用于加载和存储的模板参数。

最佳答案

写入器将 valid 标志切换为 false 并开始写入数据,而读取器可能仍在读取数据。

设计缺陷在于错误的假设,即读取和写入同一内​​存区域不是问题,只要读取器在完成读取后检查数据有效性即可。

C++ 标准称之为数据竞争,它会导致未定义的行为。

正确的解决方案是使用 std::shared_mutex 来管理对单个写入器和多个读取器的访问。

关于c++ - atomic<bool> 与受互斥锁保护的 bool,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38146681/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com