RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cplusplus.com/reference/mutex/unique_lock/operator=/ below:

public member function

<mutex>

std::unique_lock::operator= move (1)

unique_lock& operator= (unique_lock&& x) noexcept;

copy [deleted] (2)

unique_lock& operator= (const unique_lock&) = delete;

move (1)

unique_lock& operator= (unique_lock&& x);

copy [deleted] (2)

unique_lock& operator= (const unique_lock&) = delete;

Move-assign unique_lock

Replaces the managed mutex object by the one in x, including its owning state.

If the object owned a lock on its managed mutex object before the call, its unlock member is called before being replaced.

x is left in the same state as if default-constructed (referring to no mutex object).

unique_lock objects cannot be copied (2).

Parameters

x: Another unique_lock object.

Return value*this
Example

// unique_lock::operator= example
#include <iostream>       // std::cout
#include <thread>         // std::thread
#include <mutex>          // std::mutex, std::unique_lock

std::mutex mtx;           // mutex for critical section

void print_fifty (char c) {
  std::unique_lock<std::mutex> lck;         // default-constructed
  lck = std::unique_lock<std::mutex>(mtx);  // move-assigned
  for (int i=0; i<50; ++i) { std::cout << c; }
  std::cout << '\n';
}

int main ()
{
  std::thread th1 (print_fifty,'*');
  std::thread th2 (print_fifty,'$');

  th1.join();
  th2.join();

  return 0;
}

Possible output (order of lines may vary, but characters are never mixed):

**************************************************
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Data races Both the object and x are modified.
The mutex object managed by the object before the call may be modified if unlocked (as an atomic operation, causing no data races).
The mutex object managed by x is not accessed by the operation (it is only transferred).

Exception safety

No-throw guarantee: never throws exceptions.

If the object

owns a lock

on a managed

mutex object

before the call, that -for some reason- is not currently locked by the calling thread, it causes

undefined behavior

on the attempt to

unlock it

Otherwise, it throws no exceptions (no-throw guarantee).