std::mutex是否公平
Is std::mutex fair?
正如问题所述,std::mutex
公平吗?也就是说,如果线程A锁定了互斥体,然后B和C按此顺序对其调用"lock()",他们会按相同顺序获得互斥体的锁吗?还是顺序未指定?
文档中根本没有提到这一点。
标准(§30.4)没有提到任何关于互斥体上竞争线程之间公平性的要求,所以它可能是公平的,也可能不是公平的。
在实践中,std::mutex
实现可能会使用其平台提供的任何互斥实现,这是最不公平的,因为这通常更简单、更高效。在windows上,例如互斥锁通常是公平的,但并不总是如此。一些实现,例如线程构建块提供了公平的特殊互斥,但这些互斥不是基于操作系统的本机互斥,通常被实现为旋转锁(有自己的注意事项)。
如果文档没有解决这个问题,我们可以建议它是未指定的,如果没有指定,你可能会惊讶地发现他们以他们要求的相同顺序获得锁。。。
为了确保线程按照要求的顺序获得互斥,我建议您查看std::condition_variable
或std::condition_variable_any
。
它们都是在<condition_variable>
库头中声明的。在这两种情况下,它们都需要使用互斥锁来提供适当的同步。
下面是一个如何使用它的小例子:
#include <mutex>
#include <condition_variable>
std::mutex mut;
std::queue<dummyData> data;
std::condition_variable cond;
void dummyDataPrepare()
{
while( more_data_in_preparation() )
{
std::lock_guard<std::mutex> lo( mut );
// doing many things on data
cond.notify_one();
}
}
void dummyDataProcessingThread()
{
while( true )
{
std::unique_lock<std::mutex> lo( mut );
cond.wait( lo,
[]{ return !data.empty(); });
// Do whatever you want ...
lo.unlock();
}
}
这个例子展示了如何在处理一些数据之前等待处理。
相关文章:
- 如何在没有死锁和/或争用的情况下正确使用 std::mutex C++?
- std::mutex 如何防止线程修改?
- DRD 报告"conflicting load" std::mutex::lock 上的错误
- std::atomic 和 std::mutex 的相对性能
- 如何解决"'mutex' in namespace 'std' does not name a type"?
- std::lock_guard 怎么可能比 std::mutex::lock() 更快?
- 当"std::lock_guard<std::mutex>"对象没有名称时的不同行为
- std::mutex::lock() 产生奇怪(和不必要的)ASM 代码
- 使用 std::mutex 保护环路
- std::mutex作为一个成员变量对多个线程来说是安全的吗
- std::shared_timed_mutex何时比std::mutex慢,以及何时(不)使用它
- std::mutex 的发布-获取可见性保证是否仅适用于关键部分?
- 死锁使用 std::mutex 来保护多个线程中的 cout
- 返回持有 std::mutex 锁的 RAII 容器类
- 在 C++11 线程中,std::mutex 对内存可见性有什么保证?
- 在任何地方对C++中所有并行线程中的所有锁定和解锁实例使用相同的 std::mutex 和 lock 对象
- 有什么理由C++ 11+ std::mutex 应该声明为全局变量,而不是作为函数参数传递到 std::thread 中
- 将 std::atomic<bool> 与 std::mutex 结合使用的正确性
- Inline STD :: MUTEX在标题文件中
- Using std::mutex, std::condition_variable and std::unique_lo