gpt4 book ai didi

c++ - 将虚拟锁传递给 std::condition_variable_any::wait

转载 作者:塔克拉玛干 更新时间:2023-11-03 00:38:58 33 4
gpt4 key购买 nike

假设有三个线程A、B、C,B和C在某个点挂起,等待A发信号让它们继续。在标准 C++ 提供的线程同步工具中,std::condition_variable 似乎最适合放在这里(尽管仍然不好)。由于 std::condition_variable 必须与锁一起使用,因此 B 和 C 的代码可能包含如下行:

{
std::mutex mut;
std::unique_lock<std::mutex> lock(mut);
cond_var.wait(lock); // cond_var is a global variable of type std::condition_variable`
}

请注意,此处使用 mut 根本不是为了同步目的,而只是为了适应 std::condition_variable::wait 的签名。有了这个观察,我想也许我们可以通过实现一个虚拟锁类来做得更好,比如说 dummy_lock,并将 std::condition_variable 替换为 std::condition_variable_anydummy_lock 满足 BasicLockable要求及其所有方法基本上什么都不做。由此,我们得到类似下面的代码:

{
dummy_lock lock;
cond_var.wait(lock); // cond_var is a global variable of type std::condition_variable_any`
}

如果有效的话,应该比原来的效率更高。但问题是,它是否能根据标准(这里需要语言律师)?即使可行,这也绝不是一个优雅的解决方案。那么,你们有没有更好的想法?

最佳答案

你的工作前提是错误的。

互斥量不仅保护条件谓词,它还保护条件变量本身。

因此互斥体应该与条件变量在同一范围内,所有锁都应该锁定同一个互斥体。

像这样:

// global scope
std::mutex mut;
std::condition_variable cond_var;

// thread scope
{
std::unique_lock<std::mutex> lock(mut);
cond_var.wait(lock);
}

请看这里:Why do pthreads’ condition variable functions require a mutex?

关于c++ - 将虚拟锁传递给 std::condition_variable_any::wait,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29437739/

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