Sono confuso riguardo al motivo per cui esiste lock_guard. È:Sta usando unique_lock per un'attività che può essere eseguita da lock_guard più lentamente?
unique_lock?unique_lock?lock_guard può essere implementato con un'unità di stato: un puntatore o un riferimento al tipo Mutex bloccato.
unique_lock deve entrambi sostengono che lo stato, e sapendo se è attualmente bloccato, come unique_lock può avere un Mutex che non è bloccato. Ciò significa che deve avere almeno uno bool di stato aggiuntivo.
lock_guard fornisce un nullo sovraccarico RAII blocco/sblocco involucro intorno acquisire e rilasciare un Mutex. Fondamentalmente il lock_guard significa che non vi è alcun motivo per evitare l'uso di RAII per gestire i blocchi su un Mutex.
può raggiungere zero spese generali se il compilatore può essere convinto di notare che è possibile utilizzarlo solo in modi che è possibile utilizzare lock_guard (cioè, costruirlo, quindi distruggerlo, senza armeggiare con esso).
Oltre a questi argomenti di efficienza, un programmatore che vede un lock_guard sa che durerà fino alla fine dell'ambito senza dover esaminare il codice nell'ambito. Un programmatore che vede un unique_lock deve esaminare tutto l'uso della variabile per sapere se questo è il caso.
Ma quanto sopra è solo metà del motivo.
L'altra metà del motivo è perché gran parte della libreria di threading per C++ 11 era basata su librerie boost, che avevano già implementato una libreria di threading per lo più indipendente dalla piattaforma. Boost ha sia lock_guard e unique_lock, con semantica quasi identica alle versioni C++ 11.
Così, quando la libreria di threading boost era standardizzata, entrambi sono stati trasportati e nessuno li ha eliminati.
Quasi rispondere alla tua stessa domanda qui - 1) e 2) sono entrambi buoni motivi. std::lock_guard è un oggetto di blocco con ambito semplice. Funzioni come un timeout sull'acquisizione mutex si sommano alla complessità del primitivo mutex, aumentando sia il tempo necessario per eseguire l'operazione sia la probabilità di contesa per il mutex. Quindi, perché pagare per ciò che non ti serve?
Se "try_locking" con o senza timeout è un buon design è un'altra domanda; come la cancellazione dei thread, un design rotto che C++ 11 non implementa.