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
Défini dans l'en-tête <mutex>
struct defer_lock_t { explicit defer_lock_t ( ) = default ; } ;
(1) (depuis C++11)
constexpr std:: defer_lock_t defer_lock { } ;
(2) (depuis C++11)
(inline depuis C++17)
struct try_to_lock_t { explicit try_to_lock_t ( ) = default ; } ;
(3) (depuis C++11)
constexpr std:: try_to_lock_t try_to_lock { } ;
(4) (depuis C++11)
(inline depuis C++17)
struct adopt_lock_t { explicit adopt_lock_t ( ) = default ; } ;
(5) (depuis C++11)
constexpr std:: adopt_lock_t adopt_lock { } ;
(6) (depuis C++11)
(inline depuis C++17)
1,3,5) Les types de balises de classe vides std::defer_lock_t , std::try_to_lock_t et std::adopt_lock_t peuvent être utilisés dans la liste des paramètres du constructeur pour std::unique_lock et std::shared_lock pour spécifier la stratégie de verrouillage.
2,4,6) Les instances correspondantes std::defer_lock , std::try_to_lock et std::adopt_lock de (1,3,5) peuvent être passées aux constructeurs pour indiquer le type de stratégie de verrouillage.

L'un des constructeurs de la classe template std::lock_guard n'accepte que l'étiquette std::adopt_lock .

Type Effet(s)
defer_lock_t n'acquiert pas la propriété du mutex
try_to_lock_t tente d'acquérir la propriété du mutex sans bloquer
adopt_lock_t suppose que le thread appelant possède déjà la propriété du mutex

Exemple

#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) // éviter l'interblocage en cas d'auto-transfert
        return;
    // verrouiller les deux mutex sans interblocage
    std::lock(from.m, to.m);
    // s'assurer que les deux mutex déjà verrouillés sont déverrouillés en fin de portée
    std::lock_guard lock1{from.m, std::adopt_lock};
    std::lock_guard lock2{to.m, std::adopt_lock};
// approche équivalente :
//  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';
}

Sortie :

my_account.balance = 95
your_account.balance = 55

Voir aussi

construit un lock_guard , verrouillant optionnellement le mutex donné
(fonction membre publique de std::lock_guard<Mutex> )
construit un unique_lock , verrouillant optionnellement (c'est-à-dire prenant possession de) le mutex fourni
(fonction membre publique de std::unique_lock<Mutex> )