Mutex of the C + + standard library

The mutex has a reentrant, non-reentrant score. In the C + + standard library, a mutex is used to represent a non-reentrant mutex, and a recursive_mutex is used to represent a reentrant mutex. For these two classes to increase the ability to block threads based on time, there are two new mutex locks: timed_mutex (non-reentrant locks), Recursive_timed_mutex (reentrant locks).

All mutexes of the C + + standard library are non-copy and cannot be moved.

Mutex basic operations

Lock Lock If the mutex is unlocked, lock it. Otherwise, if there is another thread lock, the current thread is blocked.

Lock Try_lock If the mutex is unlocked, lock it. Otherwise returns false, and does not block the current thread.

unlock unlock If the mutex is locked by the current thread, it will be unlocked. Otherwise, the behavior is undefined.

Timed_mutex adds the following two actions on the basis of a mutex

try_lock_for (Duration) If the Timed_mutex is unlocked, lock it, otherwise block the current thread, but only block the time period represented by duration.

try_lock_until (time_point) If the Timed_mutex is unlocked, lock it, or block the current thread, but the longest will only block until the point at which the time_point represents is no longer blocked.

The reentrant lock Recursive_mutex, Recursive_timed_mutex are consistent with the corresponding mutex, Timed_mutex operation. The difference is that a non-reentrant lock can cause a deadlock when lock or Try_lock is already locked by the current thread, and a reentrant lock will not.

Auxiliary class Template<class mutex> class Lock_guard;

The Lock_guard is used to unlock the mutex automatically after the lifetime of the Lock_guard object.

Explicit Lock_guard (Mutex_type &m), object creation when execute M.lock (), object destroyed when execute M.unlock ()

Explicit Lock_guard (Mutex_type &m,adpot_lock_t tag), object creation does not execute lock, object is destroyed when the M.unlock () is executed. So m should be a mutex that has been lock by the current thread.

Template<class mutex> class Unique_lock;

Unique_lock () noexcept; do not manage any locks.

Explicit Unique_lock (Mutex_type &m); execute M.lock () when object is created.

Unique_lock (mutex_type &m,try_to_lock_t tag); M.try_lock () is executed when the object is created.

Unique_lock (mutex_type &m,defer_lock_t tag), when the object is created without a lock operation, m satisfies the condition that is not locked by the current thread.

Unique_lock (mutex_type &m,adopt_lock_t tag), when the object is created without a lock operation, m satisfies the condition that has been locked by the current thread.

Unique_lock (Mutex_type &m,const duration & real_time); execute m.try_lock_for (real_time) when object is created.

Unique_lock (Mutex_type &m,const time_point & abs_time); execute M.try_lock_until (abs_time) when object is created.

Unique_lock (Unique_lock &&); Mobile construction

Action: Unique_lock has all the operations of the lock it manages lock, unlock, Try_lock, Try_lock_for, Try_lock_until.

Mutex_type *release (); Mutexes are no longer managed.

void Swap (Unique_lock &); Interchange managed mutex.

the bool Owns_lock () is used to detect whether the Unique_lock manages a mutex and is locked. BOOL operate bool () is equivalent to Owns_lock.

Mutex_type * Mutex (), which returns a pointer to a managed mutex, but still manages it.

When the Unique_lock is destroyed, Owns_lock will execute unlock.

Generally speaking, Lock_guard is more efficient in time and space, but has a single function. Unique_lock has many functions, flexible use, but less space efficiency than lock_guard.

Mutex of the C + + standard library