std::defer_...dopt_lock_t(3)
π NAME π
okay bestie, this is the std::defer_...dopt_lock_t(3) page from the C++ Standard Libary manual, and it's literally about std::defer_lock_t, std::try_to_lock_t, and std::adopt_lock_t β the original NAME line is std::defer_lock_t,std::try_to_lock_t,std::adopt_lock_t, and yes, all three are the main characters here π
β¨
β¨ Synopsis β¨
Defined in header <mutex>
struct defer_lock_t { explicit defer_lock_t() = default; };
struct try_to_lock_t { explicit try_to_lock_t() = default; }; (since C++11)
struct adopt_lock_t { explicit adopt_lock_t() = default; };
std::defer_lock_t, std::try_to_lock_t, and std::adopt_lock_t are empty class tag types used to specify locking strategy for std::unique_lock and std::shared_lock. no cap, that's their whole job π«Ά
Here's the type / effect(s) vibe check:
defer_lock_tβ do not acquire ownership of the mutextry_to_lock_tβ try to acquire ownership of the mutex without blockingadopt_lock_tβ assume the calling thread already has ownership of the mutex
π Example π
// Run this code β literally go run it, bestie π
#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) // avoid deadlock in case of self transfer
return;
// lock both mutexes without deadlock
std::lock(from.m, to.m);
// make sure both already-locked mutexes are unlocked at the end of
scope
std::lock_guard lock1{from.m, std::adopt_lock};
std::lock_guard lock2{to.m, std::adopt_lock};
// equivalent approach:
// 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';
}
Output:
my_account.balance = 95
your_account.balance = 55
πΈ Defect reports πΈ
The following behavior-changing defect reports were applied retroactively to previously published C++ standards. iykyk, retroactive lore β¨
- DR
LWG 2510; applied toC++11; behavior as published: the default constructors were non-explicit, which could lead to ambiguity; correct behavior: made explicit.
π¦ See also π¦
defer_lock,try_to_lock,adopt_lockβ tag constants used to specify locking strategy;(constant);(C++11)(C++11)(C++11)- constructor β constructs a
lock_guard, optionally locking the given mutex; public member function ofstd::lock_guard<Mutex> - constructor β constructs a
unique_lock, optionally locking (i.e., taking ownership of) the supplied mutex; public member function ofstd::unique_lock<Mutex>
okay that's the whole page π source: http://cppreference.com; version/date: 2024.06.10; manual page: std::defer_...dopt_lock_t(3). byeee, go lock safely π«Άπ
π¦ where this page comes from
- nixpkgs unstable: stdman 2024.07.05
- opensuse-leap 16.0: stdman 2024.07.05-bp160.1.9 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms