Namespaces
Variants

std:: defer_lock, std:: try_to_lock, std:: adopt_lock, std:: defer_lock_t, std:: try_to_lock_t, std:: adopt_lock_t

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
(C++11)
defer_lock try_to_lock adopt_lock defer_lock_t try_to_lock_t adopt_lock_t
(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)
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
Definiert im Header <mutex>
struct defer_lock_t { explicit defer_lock_t ( ) = default ; } ;
(1) (seit C++11)
constexpr std:: defer_lock_t defer_lock { } ;
(2) (seit C++11)
(inline seit C++17)
struct try_to_lock_t { explicit try_to_lock_t ( ) = default ; } ;
(3) (seit C++11)
constexpr std:: try_to_lock_t try_to_lock { } ;
(4) (seit C++11)
(inline seit C++17)
struct adopt_lock_t { explicit adopt_lock_t ( ) = default ; } ;
(5) (seit C++11)
constexpr std:: adopt_lock_t adopt_lock { } ;
(6) (seit C++11)
(inline seit C++17)
1,3,5) Die leeren Klassentag-Typen std::defer_lock_t , std::try_to_lock_t und std::adopt_lock_t können in der Parameterliste des Konstruktors für std::unique_lock und std::shared_lock verwendet werden, um die Sperrstrategie anzugeben.
2,4,6) Die entsprechenden std::defer_lock , std::try_to_lock und std::adopt_lock Instanzen von (1,3,5) können an die Konstruktoren übergeben werden, um die Art der Sperrstrategie anzugeben.

Einer der Konstruktoren der Klassenvorlage std::lock_guard akzeptiert ausschließlich den Tag std::adopt_lock .

Typ Effekt(e)
defer_lock_t erwirbt keinen Besitz des Mutex
try_to_lock_t versucht Besitz des Mutex ohne Blockierung zu erlangen
adopt_lock_t nimmt an, dass der aufrufende Thread bereits Besitz des Mutex hat

Beispiel

#include <iostream>
#include <mutex>
#include <thread>
struct bank_account
{
    explicit bank_account(int balance) : balance{balance} {}
    int balance;
    std::mutex m;
};
void transfer(bank_account& from, bank_account& to, int amount)
{
    if (&from == &to) // Deadlock bei Selbstüberweisung vermeiden
        return;
    // Beide Mutexe ohne Deadlock sperren
    std::lock(from.m, to.m);
    // Sicherstellen, dass beide bereits gesperrten Mutexe am Ende des Gültigkeitsbereichs entsperrt werden
    std::lock_guard lock1{from.m, std::adopt_lock};
    std::lock_guard lock2{to.m, std::adopt_lock};
// Äquivalenter Ansatz:
//  std::unique_lock<std::mutex> lock1{from.m, std::defer_lock};
//  std::unique_lock<std::mutex> lock2{to.m, std::defer_lock};
//  std::lock(lock1, lock2);
    from.balance -= amount;
    to.balance += amount;
}
int main()
{
    bank_account my_account{100};
    bank_account your_account{50};
    std::thread t1{transfer, std::ref(my_account), std::ref(your_account), 10};
    std::thread t2{transfer, std::ref(your_account), std::ref(my_account), 5};
    t1.join();
    t2.join();
    std::cout << "my_account.balance = " << my_account.balance << "\n"
                 "your_account.balance = " << your_account.balance << '\n';
}

Ausgabe:

my_account.balance = 95
your_account.balance = 55

Siehe auch

Konstruiert einen lock_guard , optional sperrend den gegebenen Mutex
(öffentliche Mitgliedsfunktion von std::lock_guard<Mutex> )
Konstruiert einen unique_lock , optional sperrend (d.h. Besitz übernehmend) den bereitgestellten Mutex
(öffentliche Mitgliedsfunktion von std::unique_lock<Mutex> )