c++ - lock_guard で完了できるタスクに unique_lock を使用すると遅くなりますか?

Question

存在する理由について混乱していlock_guardます。それは...ですか：

1. unique_lock?よりもシンプルなインターフェース
2. よりも優れたunique_lockパフォーマンス
3. 他の何か？

Answer 1

lock_guardMutexロックされた型へのポインタまたは参照という状態の 1 つの単位で実装できます。

unique_lockはロックされていないを持つことができるため、その状態を保持することと、現在ロックされているかどうかを知る必要があります。これは、少なくとも余分な状態が必要であることを意味します。unique_lockMutexbool

lock_guardの取得と解放に関するゼロオーバーヘッド RAII ロック/ロック解除ラッパーを提供しますMutex。基本的にlock_guardは、RAII を使用して のロックを処理することを避ける理由がないことを意味しMutexます。

unique_lock使用可能な方法でのみ使用することをコンパイラーが認識できる場合にのみ、オーバーヘッドをゼロにすることlock_guardができます (つまり、それを構築し、それをいじらずに破棄するなど)。

これらの効率の議論を超えて、a を見たプログラマーはlock_guard、スコープ内のコードを調べる必要なく、スコープの終わりまで続くことを知っています。を見たプログラマーunique_lockは、変数のすべての使用を調べて、これが事実であるかどうかを知る必要があります。

しかし、上記は理由の半分にすぎません。

もう 1 つの理由は、C++11 のスレッド ライブラリの多くがboost、ほぼプラットフォームに依存しないスレッド ライブラリを既に実装しているライブラリに基づいていたためです。Boost には と の両方がlock_guardありunique_lock、セマンティクスは C++11 バージョンとほぼ同じです。

そのため、スレッド化ライブラリが標準化されたときboost、両方が導入され、誰もそれらを排除しませんでした。