In this guide, we will explore the std::deferlockt, std::trytolockt, and std::adoptlockt in C++, along with their syntax and usage examples. These three tag variants, namely std::deferlockt, std::trytolockt, and std::adoptlockt, are commonly employed in C++ in combination with std::uniquelock and std::lockguard to specify the locking strategy when dealing with mutexes.
What is the Std::defer_lock_t?
Delaying the act of locking when initializing an object, like std::uniquelock or std::lockguard, can be achieved with the std::deferlock tag type. When a lock object is instantiated with std::deferlock, the associated mutex remains unlocked initially. Later on, we can manually lock the mutex by calling the lock member function.
Syntax:
It has the following syntax:
std::mutex mutex;
std::unique_lock<std::mutex> lock(mutex, std::defer_lock);
// Mutex is not locked yet
lock.lock(); // Now, the mutex is locked
What is the Std::try_to_lock_t?
The objective of this specific tag is to attempt acquiring the lock without causing any obstructions. The lock constructor will not cause any delays, and the lock instance will be generated in an unlocked state if the lock is not currently accessible. This functionality allows us to make attempts at acquiring the lock using non-blocking techniques.
Syntax:
It has the following syntax:
std::mutex mutex;
std::unique_lock<std::mutex> lock(mutex, std::try_to_lock);
if (lock.owns_lock()) {
// Lock was acquired successfully
} else {
// Lock was not acquired
}
What is the Std::adopt_lock_t?
This specific tag is employed to signify that the current thread already possesses the lock linked to the mutex. Typically, when transferring a lock from one scope to another, it is commonly utilized for this particular scenario.
Syntax:
It has the following syntax:
std::mutex mutex;
mutex.lock(); // Lock the mutex
std::unique_lock<std::mutex> lock(mutex, std::adopt_lock);
// Now, the lock is owned by the unique_lock object
Example 1:
Let's consider an illustration to explain the roles of std::deferlockt, std::trytolockt, and std::adoptlock_t in C++.
#include <iostream>
#include <thread>
#include <mutex>
std::mutex mtx;
// Function to demonstrate locking behavior
void print_thread_id(std::unique_lock<std::mutex>& lock, const char* msg) {
lock.lock(); // Manually lock the mutex
std::cout << msg << " Thread ID: " << std::this_thread::get_id() << std::endl;
}
int main() {
// Example using std::defer_lock_t
{
std::unique_lock<std::mutex> lock(mtx, std::defer_lock);
print_thread_id(lock, "Deferred Locking:");
// Do some work
} // Lock is automatically released when lock goes out of scope
// Example using std::try_to_lock_t
{
std::unique_lock<std::mutex> lock(mtx, std::try_to_lock);
if (lock.owns_lock()) {
print_thread_id(lock, "Try To Locking:");
// Do some work
} else {
std::cout << "Try To Locking: Lock was not acquired immediately." << std::endl;
}
}
// Example using std::adopt_lock_t
{
mtx.lock(); // Lock the mutex manually before creating the lock
std::unique_lock<std::mutex> lock(mtx, std::adopt_lock);
print_thread_id(lock, "Adopt Locking:");
// Do some work
} // Lock is not unlocked automatically because it was adopted
return 0;
}
Output:
Deferred Locking: Thread ID: 135034438377280
terminate called after throwing an instance of 'std::system_error'
what(): Resource deadlock avoided
Aborted
Explanation:
In this instance, the following code demonstrates the application of each tag type in different scenarios. Initially, the locking process is delayed until it is explicitly requested using std::deferlock. In the third case, std::adoptlock assumes that the current thread already possesses the lock, whereas in another situation, std::trytolock tries to acquire the lock without causing any delays.
Example 2:
Let's consider another scenario to explain the std::deferlockt, std::trytolockt, and std::adoptlock_t in C++.
#include <iostream>
#include <thread>
#include <mutex>
std::mutex mtx;
// Function to demonstrate locking behavior
void print_thread_id(const char* msg) {
std::lock_guard<std::mutex> lock(mtx); // Lock the mutex
std::cout << msg << " Thread ID: " << std::this_thread::get_id() << std::endl;
} // Lock is automatically released when lock goes out of scope
int main() {
// Example using std::defer_lock_t
{
std::unique_lock<std::mutex> lock(mtx, std::defer_lock);
print_thread_id("Deferred Locking:");
// Do some work
lock.lock(); // Explicitly lock the mutex
}
// Example using std::try_to_lock_t
{
std::unique_lock<std::mutex> lock(mtx, std::try_to_lock);
if (lock.owns_lock()) {
print_thread_id("Try To Locking:");
// Do some work
} else {
std::cout << "Try To Locking: Lock was not acquired immediately." << std::endl;
}
}
// Example using std::adopt_lock_t
{
mtx.lock(); // Lock the mutex manually
std::unique_lock<std::mutex> lock(mtx, std::adopt_lock);
print_thread_id("Adopt Locking:");
// Do some work
} // Lock is automatically released when unique_lock goes out of scope
return 0;
}
Output:
Deferred Locking: Thread ID: 138276743659328
Try To Locking: Thread ID: 138276743659328
Adopt Locking: Thread ID: 138276743659328
Conclusion:
In summary, the std::deferlockt, std::trytolockt, and std::adoptlockt tag categories provide crucial flexibility when managing mutexes in concurrent programming. The std::deferlockt allows controlling the locking sequence by enabling a mutex to be locked without an immediate request. For scenarios where immediate lock acquisition is not feasible, the std::trytolockt facilitates non-blocking lock acquisition by attempting to acquire the lock without blocking. Moreover, the std::adoptlockt signifies that the calling thread already holds the lock associated with the mutex, beneficial in scenarios where a mutex is shared among multiple program components or when transferring lock ownership is necessary. These tag types, primarily used with std::uniquelock and std::lockguard, enable the creation of more expressive, efficient, and dependable concurrent C++ code.
