Shulou(Shulou.com)06/03 Report--

Today, I will talk to you about how to understand Lock in C++11. Many people may not know much. In order to let everyone know more, Xiaobian summarized the following contents for everyone. I hope everyone can gain something according to this article.

C++11 standard lock types are described in detail.

The C++11 standard provides us with two basic lock types, as follows:

std::lock_guard, which is related to Mutex RAII and makes it easier for threads to lock mutex. std::unique_lock, which is related to Mutex RAII and makes it easier for threads to lock mutexes, but provides better locking and unlocking control.

There are also several Tag classes associated with lock types, as follows:

std::adopt_lock_t, an empty tag class defined as follows:

struct adopt_lock_t {};

The constant object of this type adopt_lock (adopt_lock is a constant object defined as follows:

constexpr adopt_lock_t adopt_lock {};,// constexpr is a new keyword in C++11)

Constructor that is usually passed as an argument to unique_lock or lock_guard.

std::defer_lock_t, an empty tag class defined as follows:

struct defer_lock_t {};

The constant object of this type defer_lock (defer_lock is a constant object defined as follows:

constexpr defer_lock_t defer_lock {};,// constexpr is a new keyword in C++11)

Constructor that is usually passed as an argument to unique_lock or lock_guard.

std::try_to_lock_t, an empty tag class defined as follows:

struct try_to_lock_t {};

A constant object of this type try_to_lock (try_to_lock is a constant object defined as follows:

constexpr try_to_lock_t try_to_lock {};,// constexpr is a new keyword in C++11)

Constructor that is usually passed as an argument to unique_lock or lock_guard. We'll explain in detail how the three Tag types differ when used with lock_gurad and unique_lock.

std::lock_guard Introduction

std::lock_gurad is a template class defined in C++11. Defined as follows:

template class lock_guard;

Lock_guard object is usually used to manage a lock object, so it is related to Mutex RAII, which facilitates threads to lock mutex, that is, during the declaration period of a lock_guard object, the lock object it manages will always remain locked; after the life cycle of lock_guard ends, the lock object it manages will be unlocked (Note: Smart pointers like shared_ptr manage dynamically allocated memory resources).

Template parameter Mutex represents mutex type, such as std::mutex type, which should be a basic BasicLockable type. There are several basic BasicLockable types defined in the standard library, namely std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex (all four types were introduced in the previous blog) and std::unique_lock(std::unique_lock will be introduced later in this article). (Note: BasicLockable objects only need to satisfy two operations, lock and unlock. In addition, there are Lockable types. On the basis of BasicLockable types, try_lock operation is added. Therefore, an object satisfying Lockable should support three operations: lock, unlock and try_lock. Finally, there is a TimedLockable object, which adds try_lock_for and try_lock_until to the Lockable type, so an object satisfying TimedLockable should support five operations: lock, unlock, try_lock, try_lock_for, try_lock_until).

When the lock_guard object is constructed, the incoming Mutex object (i.e., the Mutex object it manages) is locked by the current thread. When the lock_guard object is destructed, the Mutex object managed by it will be automatically unlocked. Since the programmer does not need to manually call lock and unlock to lock and unlock the Mutex, this is also the simplest and safest way to lock and unlock. Especially, the Mutex object that has been locked before can be unlocked correctly after the program throws an exception, which greatly simplifies the programmer's writing of exception handling code related to Mutex.

It is worth noting that the lock_guard object is not responsible for managing the life cycle of Mutex objects. The lock_guard object only simplifies the locking and unlocking operations of Mutex objects, which facilitates threads to lock mutexes. That is, during the declaration cycle of a lock_guard object, the lock objects it manages will always remain locked; after the life cycle of lock_guard ends, the lock objects it manages will be unlocked.

std::lock_guard constructor

The lock_guard constructor is shown in the following table:

explicit lock_guard (mutex_type& m);

lock_guard (mutex_type& m, adopt_lock_t tag);

lock_guard (const lock_guard&) = delete;

locking (1)adopting (2)copy [deleted](3)

locking initializes the lock_guard object to manage the Mutex object m and lock m at construction time (call m.lock()).

adopting initialization lock_guard object manages Mutex object m, unlike locking initialization (1), Mutex object m has been locked by the current thread.

Copy construction and move construction are disabled for lock_guard objects, so lock_guard objects cannot be copy constructed or move constructed.

Let's look at a simple example (see below):

#include // std::cout#include // std::thread#include // std::mutex, std::lock_guard, std::adopt_lockstd::mutex mtx; // mutex for critical sectionvoid print_thread_id (int id) { mtx.lock(); std::lock_guard lck(mtx, std::adopt_lock); std::cout

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.