C++ 11標準でunique_lock :: unlock underspecifiedですか？

Question

C++ 11標準定義unique_lock::unlockとして（30.4.2.2.2、Pを§1159）

void unlock(); 
Effects: pm->unlock() 
Postcondition: owns == false 
Throws: system_error when an exception is required (30.2.2). 
Error conditions: 
    — operation_not_permitted — if on entry owns is false. 

を他のすべてのロック操作例外は、少なくとも2つの機会にスローされることを指定：

• ミューテックスは（errc::operation_not_permittedとsystem_errorをスロー）
• ミューテックスが既にロックされている（errc::operation_not_permittedでsystem_errorをスロー）

NULLであります

無効なmutexの問題は明らかにunlockでも可能ですが、標準ではロック問題のプログラムの動作のみを指定しています。それは標準の本当の誤りですか、私は何かを逃していますか？

Answer 1

を固定して、最後のパブリックドラフトから働いている：

if pm == nullptr then owns == false 
if owns == true then pm != nullptr 

取得する方法だけではありませんunique_lockは未定義の振る舞い以外のこれらの不変条件に違反する状態になります。従って節：

— operation_not_permitted — if on entry owns is false. 

は、pm == nullptrの場合をカバーします。

~unique_lock()は、ownsがtrueの場合にのみpm->unlock()を呼び出します。 ownsが真の場合、pm != nullptr、したがってunlock()は投げられません。

Answer 2

pmはmutex_typeあるとstd::mutexでロック解除のための定義は次のとおりです。

ある

void unlock() noexcept; 

は、unlock機能は、したがって、unique_lock::unlockは、これらの例外のいずれかを継承する必要はありません、すべての例外をスローすることはできません。なぜそれがすべての例外をスローすることができるかについては、謎です。

unique_lockのデストラクタが例外をスローする可能性があります（私はそれがunlockを呼び出す必要があるかもしれないと思うので）。これは私にとっては悪いようです。なぜなら、例外処理中に適切にロックを解除するためにロックオブジェクトを使用するのは非常に一般的なイディオムです。スタックが巻き戻し中にロックが例外をスローすることができるのは本当に悪いことです。特に、基になるmutexは許可されていないためです。

ここで何か間違いがあります。

私はまだunique_lockには、次の不変量を持ち、明示的に示されてはいないが、おそらくこれは