なぜstd::mutex::unlock()はnoexeptではないのですか？何らかの理由により、ミューテックスを所有していないスレッドがunlock()を呼び出すと、標準によってその動作は未定義のままになります。そうすることの正当性は何ですか？これにより、関数がスローした場合、std::unique_lockまたはstd::lock_guardのデストラクタ実装で、デストラクタで例外が誤ってリークすることはありませんか？スローなぜstd :: mutex :: unlock（）がnoexceptでないのですか
注デストラクタ - https://akrzemi1.wordpress.com/2011/09/21/destructors-that-throw/
委員会がなぜそれをしなかったのかはわかりません。noexcept。 noexceptは - 一般的に - 標準ライブラリ全体で、強力な例外保証を提供する効率的な関数（例えばstd::swapや移動コンストラクタ）を実装するために必要ないくつかの重要な関数に明示的にしか適用されないことを指摘することができます。
は限りstd::unique_lockなどが懸念している：実装がロック解除がunique_lockのデストラクタは、内部でそれをキャッチしなければならない、スローできるようになるので、もしそのデストラクタは、（暗黙的に）noexceptです。
実際にはありません。 'BasicLockable'は' unlock（） 'がスローしないようにする必要があります。したがって、すべてのベットがオフの場合、' terminate'は実際には良いオプションです。 'unlock（）'は契約が狭いので 'noexcept'ではありません。あなたが所有していないミューテックスのロックを解除しようとするとUBが発生し、実装が検出できれば（たとえば、デバッグモードで）例外をスローしたい場合があります。 –
std::unique_lockそれはロック「を所有している」かどうかを示すフラグを持っています。 lockを正常に呼び出すと、フラグが設定されます。 unlockに電話すると、フラグがリセットされます。
デストラクタが呼び出されたときに、ロックを所有していない場合は、unlockは呼び出されません。
ありがとう！そのとおり。しかし、 'lock_guard'の場合はどうなりますか？ – Curious
'lock_guard'のコンストラクタでは、' mutex'、つまりコンストラクタのパラメータを 'ロック 'します。だから、 'lock_guard'は常に' mutex'を所有しています。破壊すると、自身が所有する 'mutex'を'ロック解除 'しなければなりません。 –
noexceptを非常に慎重に適用し、パフォーマンスにとって重要である場合、および/または基本的/強力な例外保証を実現する場合のみ、委員会の方針の結果であると考えています。 – MikeMB