我有以下情况：
两个C ++ 11线程正在计算，它们通过std :: mutex同步。
线程A锁定互斥对象，直到数据准备好执行线程B的操作为止。互斥锁解锁后，线程B开始工作。
线程B尝试锁定互斥锁并被阻塞，直到被线程A解锁为止。
void ThreadA (std::mutex* mtx, char* data)
{
mtx->lock();
//do something useful with data
mtx->unlock();
}
void ThreadB (std::mutex* mtx, char* data)
{
mtx->lock(); //wait until Thread A is ready
//do something useful with data
//.....
}
断言线程A可以先阻止互斥量。
现在我想知道mtx->lock()线程B中的等待是主动还是被动。线程B也会轮询互斥量状态并浪费处理器时间，或者在互斥量未锁定时被Sheduler被动释放。
在不同的C ++参考文献中，仅提到了线程被阻塞，而不是以哪种方式阻塞。
但是，难道std::mutex实现几乎不取决于所使用的平台和OS？
它是高度实现的定义，即使对于相同的编译器和操作系统
例如，在Visual Studio 2010中的VC ++上，std::mutex是使用Win32实现的CRITICAL_SECTION。EnterCriticalSection(CRITICAL_SECTION*)具有一些不错的功能：首先，它尝试CRITICAL_SECTION通过一次又一次地对锁进行迭代来锁定。在指定的迭代次数之后，它将进行内核调用，使线程进入睡眠状态，直到释放锁并再次开始整个交易时才再次唤醒。在这种情况下，该机制在进入睡眠之前一次又一次轮询锁，然后控制切换到内核。
Visual Studio 2012附带了一个不同的实现。std::mutex是用Win32互斥锁实现的。Win32互斥锁立即将控件移至内核。锁没有执行主动轮询。
您可以在答案中了解有关实现开关的信息：std :: mutex性能与win32相比CRITICAL_SECTION
因此，未指定互斥锁如何获取锁。最好不要依赖这种行为。
ps。不要手动锁定互斥锁，std::lock_guard而应使用。同样，您可能希望使用condition_variable更精细的方式来控制同步。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句