lock_guardによって遅く実行できるタスクにunique_lockを使用していますか？

Question

なぜlock_guardが存在するのか混乱しています。それ：

1. unique_lockより簡単なインターフェイスですか？
2. unique_lockよりもパフォーマンスが優れていますか？
3. 他に何かありますか？

Answer 1

lock_guardは、ロックされたMutexタイプへのポインタまたは参照を1つの状態単位で実装できます。

unique_lockはその状態を保持し、かつunique_lockがロックされていないMutexを持つことができるよう、現在、をロックされている場合を知るために両方があります。つまり、余分な状態の少なくともboolが必要です。

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

unique_lockは、コンパイラがlock_guardが使用できる方法でしか使用できないことに気付くことができる場合（すなわち、構築してから、破壊することなく）ゼロオーバーヘッドに達することができます。

lock_guardと表示されるプログラマーは、効率の議論を超えて、スコープ内のコードを調べることなくスコープの終わりまで持続することを知っています。 unique_lockと表示されているプログラマは、変数が使用されているかどうかを知るために変数の使用方法をすべて調べなければなりません。

しかし、これは理由の半分に過ぎません。

もう1つの理由の半分は、C++ 11のスレッディングライブラリの多くが、プラットフォームのほとんどが独立したスレッドライブラリをすでに実装していたboostライブラリに基づいているためです。 Boostはlock_guardとunique_lockの両方を持ち、C++ 11バージョンとほとんど同じセマンティクスを持っています。

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

Answer 2

ほとんどあなた自身の質問に答えてください - 1）と2）両方とも良い理由です。 std::lock_guardは、シンプルスコープロックオブジェクトです。ミューテックス取得時のタイムアウトなどの機能は、ミューテックスプリミティブの複雑さを増し、操作を実行するのにかかる時間とミューテックスの競合確率の両方を増加させます。だから、あなたが必要としないものをなぜ払うのですか？

タイムアウトを伴うまたは伴わないかどうか「try_lockingは」良いデザインであるが、別の質問です。 C++ 11が実装していない壊れたデザインのような、スレッドキャンセルのようなものです。