Namespaces
Variants

std::unique_lock<Mutex>:: operator=

From cppreference.net
Concurrency support library
Threads
(C++11)
(C++20)
this_thread namespace
(C++11)
(C++11)
Cooperative cancellation
Mutual exclusion
Generic lock management
Condition variables
(C++11)
Semaphores
Latches and Barriers
(C++20)
(C++20)
Futures
(C++11)
(C++11)
(C++11)
Safe reclamation
Hazard pointers
Atomic types
(C++11)
(C++20)
Initialization of atomic types
(C++11) (deprecated in C++20)
(C++11) (deprecated in C++20)
Memory ordering
(C++11) (deprecated in C++26)
Free functions for atomic operations
Free functions for atomic flags
unique_lock & operator = ( unique_lock && other ) noexcept ;
(since C++11)

Move assignment operator. Equivalent to unique_lock { std :: move ( other ) } . swap ( * this ) ; return * this ; .

If other is the same object as * this , there is no effect. Otherwise, if prior to the call * this has an associated mutex and has acquired ownership of it, the mutex is unlocked.

Contents

Parameters

other - another unique_lock to replace the state with

Return value

* this

Notes

With a recursive mutex it is possible for both * this and other to own the same mutex before the assignment. In this case, * this will own the mutex after the assignment and other will not.

The move assignment possibly raises undefined behavior. For example, when * this is constructed with std::adopt_lock , but the calling thread does not have the ownership of the associated mutex, the ownership of the associated mutex cannot be properly released.

Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR Applied to Behavior as published Correct behavior
LWG 2104 C++11 the move assignment operator was noexcept but could have undefined behavior noexcept removed
LWG 4172 C++11 LWG2104 removed noexcept
self-move-assignment of unique_lock was incorrectly specified
noexcept restored
respecified as no-op