std::unique_lock<Mutex>::operator=

From cppreference.com
< cpp‎ | thread‎ | unique lock
Concurrency support library
Threads
(C++11)
(C++20)
this_thread namespace
(C++11)
(C++11)
(C++11)
(C++11)
Cooperative cancellation
Mutual exclusion
(C++11)
(C++11)
(C++17)
Generic lock management
(C++11)
(C++11)
(C++17)
(C++11)
(C++14)
(C++11)
(C++11)
(C++11)
(C++11) (C++11) (C++11) (C++11) (C++11) (C++11)
Condition variables
(C++11)
Semaphores
Latches and Barriers
(C++20)
(C++20)
Futures
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
(C++11)
Safe Reclamation
(C++26)
(C++26)
(C++26)
Hazard Pointers
(C++26)
Atomic types
(C++11)
(C++20)
(C++11)
Initialization of atomic types
(C++11)(deprecated in C++20)
(C++11)(deprecated in C++20)
Memory ordering
(C++11)
(C++11)
Free functions for atomic operations
Free functions for atomic flags
unique_lock& operator= ( unique_lock&& other ) ;
(since C++11)

Move assignment operator. Replaces the contents with those of other using move semantics.

If prior to the call *this has an associated mutex and has acquired ownership of it, the mutex is unlocked.

Parameters

other - another unique_lock to replace the state with

Return value

*this

Exceptions

Throws nothing.

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

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 it may
throw an exception in the case of undefined behavior[1]
it is not noexcept
  1. For example, *this is constructed with std::adopt_lock, but the calling thread does not have the ownership of the associated mutex. In this case, *this