È unique_lock :: unlock sotto specificato nello standard C++ 11?

Question

I C++ 11 norma definisce unique_lock::unlock come (§ 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. 

Tutte le altre operazioni di bloccaggio specificano che viene generata un'eccezione in almeno due occasioni:

• il mutex è NULL (getta system_error con errc::operation_not_permitted)
• il mutex è già bloccato (tiri system_error con errc::operation_not_permitted)

Il problema con mutex non valido è ovviamente possibile anche per unlock, tuttavia lo standard specifica il comportamento del programma solo per i problemi di blocco. È un vero errore nello standard o mi manca qualcosa?

Answer 1

Anche se non esplicitamente dichiarato, unique_lock ha le seguenti invarianti:

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

Non c'è proprio nessun modo per ottenere lo unique_lock in uno stato che viola questi invarianti tranne che per comportamento non definito. Quindi la clausola:

— operation_not_permitted — if on entry owns is false. 

copre il caso che pm == nullptr.

Si noti che ~unique_lock() chiama solo pm->unlock() se owns è vero. Se owns è vero, allora pm != nullptr e quindi unlock() non può essere lanciato.

Answer 2

pm è il mutex_type e la definizione per sbloccare in std::mutex è:

void unlock() noexcept; 

Cioè, la funzione unlock non può gettare alcuna eccezione, quindi unique_lock::unlock non dispone di ereditare una di queste eccezioni. Il motivo per cui è possibile lanciare qualsiasi eccezione è un mistero.

È un po 'fastidioso che il distruttore per unique_lock possa generare un'eccezione (poiché suppongo che potrebbe dover chiamare unlock dove può anche). Questo mi sembra un problema, dal momento che l'utilizzo di un oggetto di blocco per sbloccare correttamente durante la gestione delle eccezioni è un linguaggio molto comune. È davvero brutto che il lock possa lanciare un'eccezione durante lo srotolamento dello stack, specialmente perché non è consentito al mutex sottostante.

Qui c'è sicuramente qualcosa di sbagliato.

sto ancora lavorando dall'ultimo progetto pubblico, forse questo è stato fissato