使用unique_lock来执行可以被lock_guard更慢地完成的任务吗？

Question

关于lock_guard存在的原因,我很困惑.是吗:

1. 比一个更简单的界面unique_lock？
2. 性能比unique_lock？
3. 别的什么？

Answer 1

lock_guard可以用一个状态单元实现:指向Mutex它已锁定类型的指针或引用.

unique_lock必须同时保持该状态,并知道它是否当前被锁定,因为它unique_lock可以具有Mutex未被锁定的状态.这意味着它必须至少具有一个bool额外的状态.

lock_guard提供零开销RAII锁定/解锁包装器围绕获取和释放a Mutex.基本上lock_guard意味着没有理由避免使用RAII来处理锁定Mutex.

unique_lock如果可以说服编译器注意到你只能以可以使用的方式使用它lock_guard(即构造它,然后销毁它,而不是摆弄它),那么只能达到零开销.

除了那些效率参数之外,一个看到a的程序员lock_guard知道它将持续到范围结束而不必检查范围中的代码.看到a的程序员unique_lock必须检查变量的所有使用,以了解是否是这种情况.

但以上只是原因的一半.

另一半原因是因为C++ 11的大部分线程库都是基于boost库,而库已经实现了一个主要独立于平台的线程库.升压既有lock_guard和unique_lock,用几乎相同的语义在C++ 11版本.

因此,当boost线程库被标准化时,两者都被带入,并且没有人消除它们.

Answer 2

你几乎在这里回答你自己的问题 - 1)和2)都是很好的理由.std :: lock_guard是一个简单的作用域锁定对象.诸如互斥锁获取超时之类的功能增加了互斥原语的复杂性,增加了执行操作所花费的时间以及互斥锁争用的可能性.那么为什么要付出你不需要的东西呢？

无论有没有超时的'try_locking'都是好的设计是另一个问题; 像线程取消,C++ 11没有实现的破碎设计.