33 Concurrency support library [thread]

33.6 Mutual exclusion [thread.mutex]

33.6.4 Mutex requirements [thread.mutex.requirements]

33.6.4.2 Mutex types [thread.mutex.requirements.mutex]

33.6.4.2.2 Class mutex [thread.mutex.class]

namespace std { class mutex { public: constexpr mutex() noexcept; ~mutex(); mutex(const mutex&) = delete; mutex& operator=(const mutex&) = delete; void lock(); bool try_lock(); void unlock(); using native_handle_type = implementation-defined; // see [thread.req.native] native_handle_type native_handle(); // see [thread.req.native] }; }

The class mutex provides a non-recursive mutex with exclusive ownership semantics.

If one thread owns a mutex object, attempts by another thread to acquire ownership of that object will fail (for try_lock()) or block (for lock()) until the owning thread has released ownership with a call to unlock().

[Note 1:

After a thread A has called unlock(), releasing a mutex, it is possible for another thread B to lock the same mutex, observe that it is no longer in use, unlock it, and destroy it, before thread A appears to have returned from its unlock call.

Implementations are required to handle such scenarios correctly, as long as thread A doesn't access the mutex after the unlock call returns.

These cases typically occur when a reference-counted object contains a mutex that is used to protect the reference count.

— end note]

The class mutex meets all of the mutex requirements ([thread.mutex.requirements]).

It is a standard-layout class ([class.prop]).

[Note 2:

A program can deadlock if the thread that owns a mutex object calls lock() on that object.

If the implementation can detect the deadlock, a resource_deadlock_would_occur error condition might be observed.

— end note]

The behavior of a program is undefined if it destroys a mutex object owned by any thread or a thread terminates while owning a mutex object.