Namensräume
Varianten
Aktionen

std::unique_lock<Mutex>::operator=

Von cppreference.com
< cpp‎ | thread‎ | unique lock
 
 
Bibliothek für nebenläufige Programmierung
Threads
(C++11)
(C++20)
this_thread Namespace
(C++11)
(C++11)
(C++11)
Kooperatives Beenden
Gegenseitiger Ausschluss
(C++11)
Allgemeines Sperrungsmanagement
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
Bedingungsvariablen
(C++11)
Semaphoren
Latches und Barriers
(C++20)
(C++20)
Futures
(C++11)
(C++11)
(C++11)
(C++11)
Sichere Wiederherstellung
(C++26)
Hazard Pointer
Atomare Typen
(C++11)
(C++20)
Initialisierung von atomaren Typen
(C++11)(veraltet in C++20)
(C++11)(veraltet in C++20)
Speicherordnung
(C++11)(deprecated in C++26)
Freie Funktionen für atomare Operationen
Freie Funktionen für atomare Flags
 
 
unique_lock& operator=( unique_lock&& other ) noexcept;
(seit C++11)

Move-Zuweisungsoperator. Äquivalent zu unique_lock{std::move(other)}.swap(*this); return *this;.

Wenn other dasselbe Objekt wie *this ist, hat dies keine Auswirkung. Andernfalls, wenn *this vor dem Aufruf ein zugehöriges Mutex hat und dessen Besitz erworben hat, wird das Mutex entsperrt.

Inhalt

[bearbeiten] Parameter

Sonstiges - ein weiterer unique_lock, um den Zustand damit zu ersetzen

[bearbeiten] Rückgabewert

*this

[bearbeiten] Anmerkungen

Mit einem rekursiven Mutex ist es möglich, dass sowohl *this als auch other vor der Zuweisung dasselbe Mutex besitzen. In diesem Fall besitzt *this das Mutex nach der Zuweisung und other nicht.

Die Move-Zuweisung kann zu undefiniertem Verhalten führen. Zum Beispiel, wenn *this mit std::adopt_lock konstruiert wird, aber der aufrufende Thread nicht der Besitzer des zugehörigen Mutex ist, kann der Besitz des zugehörigen Mutex nicht ordnungsgemäß freigegeben werden.

[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 2104 C++11 Der Move-Zuweisungsoperator war noexcept, konnte aber undefiniertes Verhalten aufweisen noexcept entfernt
LWG 4172 C++11 LWG2104 hat noexcept entfernt
Die Selbst-Move-Zuweisung von unique_lock war falsch spezifiziert
noexcept wiederhergestellt
als No-Op neu spezifiziert