Nach diesem kann unique_lock für die rekursive Sperrung verwendet werden, indem eine std::unique_lock<std::recursive_mutex> deklariert wird. und in der Tat, dass kompiliert fein.
Aus der Untersuchung des Codes (gcc 4.8.2 und 4.9.0) geht jedoch hervor, dass unique_lock nicht auf _Mutex.lock verweist, sondern die Lock-Methode selbst implementiert:
Dies verhindert eindeutig das rekursive Sperren des Mutex, und tatsächlich versucht die rekursive Sperre die resource_deadlock_would_occur -Ausnahme auszulösen.
Fehle ich hier etwas, ist das ein Fehler, oder ist die Dokumentation für unique_lock einfach falsch?
TIA !!!
Ein häufiger Fehler ist die Verwechslung von mutex mit lock . A mutex ist ein Objekt, das unter Threads geteilt werden kann (sonst wäre es nutzlos). Ein Schloss ist jedoch selbst kein Thread-sicheres Objekt. Es sollte nicht unter Threads geteilt werden. Es ist normalerweise ein lokales Objekt auf einem Stapel. Zum Beispiel:
Wenn im obigen Beispiel foo() rekursiv aufgerufen wird, haben Sie ein nicht definiertes Verhalten, weil Sie mut rekursiv sperren. Bei jeder Rekursion erhalten Sie jedoch ein neues unique_lock . Dem unique_lock ist also die Rekursion nicht bekannt. Wenn Sie foo() rekursiv aufrufen müssen, müssen Sie einen rekursiven Mutex verwenden, zum Beispiel:
Also: Ja, Sie können std::unique_lock<std::recursive_mutex> verwenden, und ja, Ihre Implementierung ist korrekt.
Tags und Links c++ multithreading locking recursive-mutex