C++ benannte Anforderungen: Mutex (seit C++11)
Von cppreference.com
< cpp | benannte req
Die Mutex-Anforderungen erweitern die Lockable-Anforderungen um die Synchronisation zwischen Threads.
Inhalt |
[bearbeiten] Anforderungen
- Lockable
- DefaultConstructible
- Destructible
- nicht kopierbar
- nicht verschiebbar
Für ein Objekt m vom Typ Mutex
- Der Ausdruck m.lock() hat die folgenden Eigenschaften:
- Verhält sich als atomare Operation.
- Blockiert den aufrufenden Thread, bis exklusiver Besitz des Mutex erlangt werden kann.
- Vorherige m.unlock()-Operationen auf demselben Mutex synchronisieren mit dieser Lock-Operation (entspricht Release-Acquire std::memory_order).
- Das Verhalten ist undefiniert, wenn der aufrufende Thread den Mutex bereits besitzt (es sei denn, m ist std::recursive_mutex oder std::recursive_timed_mutex).
- Ausnahmen vom Typ std::system_error können bei Fehlern ausgelöst werden, mit den folgenden Fehlercodes:
- std::errc::operation_not_permitted, wenn der aufrufende Thread nicht über die erforderlichen Berechtigungen verfügt.
- std::errc::resource_deadlock_would_occur, wenn die Implementierung erkennt, dass diese Operation zu einem Deadlock führen würde.
- Der Ausdruck m.try_lock() hat die folgenden Eigenschaften:
- Verhält sich als atomare Operation.
- Versucht, den exklusiven Besitz des Mutex für den aufrufenden Thread zu erlangen, ohne zu blockieren. Wenn der Besitz nicht erlangt wird, wird sofort zurückgekehrt. Die Funktion darf fehlerhaft fehlschlagen und auch dann zurückkehren, wenn der Mutex derzeit nicht von einem anderen Thread besessen wird.
- Wenn
try_lock()erfolgreich ist, synchronisieren vorherigeunlock()-Operationen auf demselben Objekt mit dieser Operation (entspricht Release-Acquire std::memory_order).lock()synchronisiert nicht mit einem fehlgeschlagenentry_lock(). - Löst keine Ausnahmen aus.
- Der Ausdruck m.unlock() hat die folgenden Eigenschaften:
- Verhält sich als atomare Operation.
- Gibt den Besitz des Mutex durch den aufrufenden Thread frei und synchronisiert mit nachfolgenden erfolgreichen Lock-Operationen auf demselben Objekt.
- Das Verhalten ist undefiniert, wenn der aufrufende Thread den Mutex nicht besitzt.
- Löst keine Ausnahmen aus.
- Alle Lock- und Unlock-Operationen auf einem einzelnen Mutex erfolgen in einer einzigen totalen Reihenfolge, die als Modifikationsreihenfolge einer atomaren Variable betrachtet werden kann: Die Reihenfolge ist spezifisch für diesen einzelnen Mutex.
[bearbeiten] Standardbibliothek
Die folgenden Standardbibliothekstypen erfüllen die Mutex-Anforderungen.
| (C++11) |
bietet grundlegende Gegenseitiger-Ausschluss-Funktionen (Klasse) |
| (C++11) |
bietet Gegenseitiger-Ausschluss-Funktionen, die von demselben Thread rekursiv gesperrt werden können (Klasse) |
| (C++11) |
bietet Gegenseitiger-Ausschluss-Funktionen, die rekursiv gesperrt werden können von demselben Thread und implementiert ein Sperren mit Timeout (Klasse) |
| (C++17) |
bietet gemeinsame Gegenseitiger-Ausschluss-Funktionen (Klasse) |
| (C++14) |
bietet gemeinsame Gegenseitiger-Ausschluss-Funktionen und implementiert ein Sperren mit Timeout (Klasse) |
| (C++11) |
bietet Gegenseitiger-Ausschluss-Funktionen, die ein Sperren mit Timeout implementieren (Klasse) |
[bearbeiten] Fehlerberichte
Die folgenden Verhaltensändernden Fehlerberichte wurden rückwirkend auf zuvor veröffentlichte C++-Standards angewendet.
| DR | angewendet auf | Verhalten wie veröffentlicht | Korrigiertes Verhalten |
|---|---|---|---|
| LWG 2309 | C++11 | lock kann std::system_error auslösenmit Fehlercode std::errc::device_or_resource_busy |
nicht erlaubt |
