33 Concurrency support library [thread]

33.6 Mutual exclusion [thread.mutex]

33.6.4 Mutex requirements [thread.mutex.requirements]

33.6.4.1 In general [thread.mutex.requirements.general]

1
#
A mutex object facilitates protection against data races and allows safe synchronization of data between execution agents.
An execution agent owns a mutex from the time it successfully calls one of the lock functions until it calls unlock.
Mutexes can be either recursive or non-recursive, and can grant simultaneous ownership to one or many execution agents.
Both recursive and non-recursive mutexes are supplied.

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

33.6.4.2.1 General [thread.mutex.requirements.mutex.general]

1
#
The mutex types are the standard library types mutex, recursive_mutex, timed_mutex, recursive_timed_mutex, shared_mutex, and shared_timed_mutex.
They meet the requirements set out in [thread.mutex.requirements.mutex].
In this description, m denotes an object of a mutex type.
[Note 1: 
The mutex types meet the Cpp17Lockable requirements ([thread.req.lockable.req]).
— end note]
2
#
The mutex types meet Cpp17DefaultConstructible and Cpp17Destructible.
If initialization of an object of a mutex type fails, an exception of type system_error is thrown.
The mutex types are neither copyable nor movable.
3
#
The error conditions for error codes, if any, reported by member functions of the mutex types are as follows:
  • (3.1)
    resource_unavailable_try_again — if any native handle type manipulated is not available.
  • (3.2)
    operation_not_permitted — if the thread does not have the privilege to perform the operation.
  • (3.3)
    invalid_argument — if any native handle type manipulated as part of mutex construction is incorrect.
4
#
The implementation provides lock and unlock operations, as described below.
For purposes of determining the existence of a data race, these behave as atomic operations ([intro.multithread]).
The lock and unlock operations on a single mutex appears to occur in a single total order.
[Note 2: 
This can be viewed as the modification order of the mutex.
— end note]
[Note 3: 
Construction and destruction of an object of a mutex type need not be thread-safe; other synchronization can be used to ensure that mutex objects are initialized and visible to other threads.
— end note]
5
#
The expression m.lock() is well-formed and has the following semantics:
6
#
Preconditions: If m is of type mutex, timed_mutex, shared_mutex, or shared_timed_mutex, the calling thread does not own the mutex.
7
#
Effects: Blocks the calling thread until ownership of the mutex can be obtained for the calling thread.
8
#
Synchronization: Prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.
9
#
Postconditions: The calling thread owns the mutex.
10
#
Return type: void.
11
#
Throws: system_error when an exception is required ([thread.req.exception]).
12
#
Error conditions:
  • (12.1)
    operation_not_permitted — if the thread does not have the privilege to perform the operation.
  • (12.2)
    resource_deadlock_would_occur — if the implementation detects that a deadlock would occur.
13
#
The expression m.try_lock() is well-formed and has the following semantics:
14
#
Preconditions: If m is of type mutex, timed_mutex, shared_mutex, or shared_timed_mutex, the calling thread does not own the mutex.
15
#
Effects: Attempts to obtain ownership of the mutex for the calling thread without blocking.
If ownership is not obtained, there is no effect and try_lock() immediately returns.
An implementation may fail to obtain the lock even if it is not held by any other thread.
[Note 4: 
This spurious failure is normally uncommon, but allows interesting implementations based on a simple compare and exchange ([atomics]).
— end note]
An implementation should ensure that try_lock() does not consistently return false in the absence of contending mutex acquisitions.
16
#
Synchronization: If try_lock() returns true, prior unlock() operations on the same object synchronize with this operation.
[Note 5: 
Since lock() does not synchronize with a failed subsequent try_lock(), the visibility rules are weak enough that little would be known about the state after a failure, even in the absence of spurious failures.
— end note]
17
#
Return type: bool.
18
#
Returns: true if ownership was obtained, otherwise false.
19
#
Throws: Nothing.
20
#
The expression m.unlock() is well-formed and has the following semantics:
21
#
Preconditions: The calling thread owns the mutex.
22
#
Effects: Releases the calling thread's ownership of the mutex.
23
#
Return type: void.
24
#
Synchronization: This operation synchronizes with subsequent lock operations that obtain ownership on the same object.
25
#
Throws: Nothing.

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] }; }
1
#
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().
2
#
[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]
3
#
The class mutex meets all of the mutex requirements ([thread.mutex.requirements]).
It is a standard-layout class ([class.prop]).
4
#
[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]
5
#
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.

33.6.4.2.3 Class recursive_mutex [thread.mutex.recursive]

🔗
namespace std { class recursive_mutex { public: recursive_mutex(); ~recursive_mutex(); recursive_mutex(const recursive_mutex&) = delete; recursive_mutex& operator=(const recursive_mutex&) = delete; void lock(); bool try_lock() noexcept; void unlock(); using native_handle_type = implementation-defined; // see [thread.req.native] native_handle_type native_handle(); // see [thread.req.native] }; }
1
#
The class recursive_mutex provides a recursive mutex with exclusive ownership semantics.
If one thread owns a recursive_mutex object, attempts by another thread to acquire ownership of that object will fail (for try_lock()) or block (for lock()) until the first thread has completely released ownership.
2
#
The class recursive_mutex meets all of the mutex requirements ([thread.mutex.requirements]).
It is a standard-layout class ([class.prop]).
3
#
A thread that owns a recursive_mutex object may acquire additional levels of ownership by calling lock() or try_lock() on that object.
It is unspecified how many levels of ownership may be acquired by a single thread.
If a thread has already acquired the maximum level of ownership for a recursive_mutex object, additional calls to try_lock() fail, and additional calls to lock() throw an exception of type system_error.
A thread shall call unlock() once for each level of ownership acquired by calls to lock() and try_lock().
Only when all levels of ownership have been released may ownership be acquired by another thread.
4
#
The behavior of a program is undefined if:
  • (4.1)
    it destroys a recursive_mutex object owned by any thread or
  • (4.2)
    a thread terminates while owning a recursive_mutex object.

33.6.4.3 Timed mutex types [thread.timedmutex.requirements]

33.6.4.3.1 General [thread.timedmutex.requirements.general]

1
#
The timed mutex types are the standard library types timed_mutex, recursive_timed_mutex, and shared_timed_mutex.
They meet the requirements set out below.
In this description, m denotes an object of a mutex type, rel_time denotes an object of an instantiation of duration, and abs_time denotes an object of an instantiation of time_point.
[Note 1: 
The timed mutex types meet the Cpp17TimedLockable requirements ([thread.req.lockable.timed]).
— end note]
2
#
The expression m.try_lock_for(rel_time) is well-formed and has the following semantics:
3
#
Preconditions: If m is of type timed_mutex or shared_timed_mutex, the calling thread does not own the mutex.
4
#
Effects: The function attempts to obtain ownership of the mutex within the relative timeout ([thread.req.timing]) specified by rel_time.
If the time specified by rel_time is less than or equal to rel_time.zero(), the function attempts to obtain ownership without blocking (as if by calling try_lock()).
The function returns within the timeout specified by rel_time only if it has obtained ownership of the mutex object.
[Note 2: 
As with try_lock(), there is no guarantee that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort to do so.
— end note]
5
#
Synchronization: If try_lock_for() returns true, prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.
6
#
Return type: bool.
7
#
Returns: true if ownership was obtained, otherwise false.
8
#
Throws: Timeout-related exceptions ([thread.req.timing]).
9
#
The expression m.try_lock_until(abs_time) is well-formed and has the following semantics:
10
#
Preconditions: If m is of type timed_mutex or shared_timed_mutex, the calling thread does not own the mutex.
11
#
Effects: The function attempts to obtain ownership of the mutex.
If abs_time has already passed, the function attempts to obtain ownership without blocking (as if by calling try_lock()).
The function returns before the absolute timeout ([thread.req.timing]) specified by abs_time only if it has obtained ownership of the mutex object.
[Note 3: 
As with try_lock(), there is no guarantee that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort to do so.
— end note]
12
#
Synchronization: If try_lock_until() returns true, prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.
13
#
Return type: bool.
14
#
Returns: true if ownership was obtained, otherwise false.
15
#
Throws: Timeout-related exceptions ([thread.req.timing]).

33.6.4.3.2 Class timed_mutex [thread.timedmutex.class]

🔗
namespace std { class timed_mutex { public: timed_mutex(); ~timed_mutex(); timed_mutex(const timed_mutex&) = delete; timed_mutex& operator=(const timed_mutex&) = delete; void lock(); // blocking bool try_lock(); template<class Rep, class Period> bool try_lock_for(const chrono::duration<Rep, Period>& rel_time); template<class Clock, class Duration> bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time); void unlock(); using native_handle_type = implementation-defined; // see [thread.req.native] native_handle_type native_handle(); // see [thread.req.native] }; }
1
#
The class timed_mutex provides a non-recursive mutex with exclusive ownership semantics.
If one thread owns a timed_mutex object, attempts by another thread to acquire ownership of that object will fail (for try_lock()) or block (for lock(), try_lock_for(), and try_lock_until()) until the owning thread has released ownership with a call to unlock() or the call to try_lock_for() or try_lock_until() times out (having failed to obtain ownership).
2
#
The class timed_mutex meets all of the timed mutex requirements ([thread.timedmutex.requirements]).
It is a standard-layout class ([class.prop]).
3
#
The behavior of a program is undefined if:
  • (3.1)
    it destroys a timed_mutex object owned by any thread,
  • (3.2)
    a thread that owns a timed_mutex object calls lock(), try_lock(), try_lock_for(), or try_lock_until() on that object, or
  • (3.3)
    a thread terminates while owning a timed_mutex object.

33.6.4.3.3 Class recursive_timed_mutex [thread.timedmutex.recursive]

🔗
namespace std { class recursive_timed_mutex { public: recursive_timed_mutex(); ~recursive_timed_mutex(); recursive_timed_mutex(const recursive_timed_mutex&) = delete; recursive_timed_mutex& operator=(const recursive_timed_mutex&) = delete; void lock(); // blocking bool try_lock() noexcept; template<class Rep, class Period> bool try_lock_for(const chrono::duration<Rep, Period>& rel_time); template<class Clock, class Duration> bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time); void unlock(); using native_handle_type = implementation-defined; // see [thread.req.native] native_handle_type native_handle(); // see [thread.req.native] }; }
1
#
The class recursive_timed_mutex provides a recursive mutex with exclusive ownership semantics.
If one thread owns a recursive_timed_mutex object, attempts by another thread to acquire ownership of that object will fail (for try_lock()) or block (for lock(), try_lock_for(), and try_lock_until()) until the owning thread has completely released ownership or the call to try_lock_for() or try_lock_until() times out (having failed to obtain ownership).
2
#
The class recursive_timed_mutex meets all of the timed mutex requirements ([thread.timedmutex.requirements]).
It is a standard-layout class ([class.prop]).
3
#
A thread that owns a recursive_timed_mutex object may acquire additional levels of ownership by calling lock(), try_lock(), try_lock_for(), or try_lock_until() on that object.
It is unspecified how many levels of ownership may be acquired by a single thread.
If a thread has already acquired the maximum level of ownership for a recursive_timed_mutex object, additional calls to try_lock(), try_lock_for(), or try_lock_until() fail, and additional calls to lock() throw an exception of type system_error.
A thread shall call unlock() once for each level of ownership acquired by calls to lock(), try_lock(), try_lock_for(), and try_lock_until().
Only when all levels of ownership have been released may ownership of the object be acquired by another thread.
4
#
The behavior of a program is undefined if:
  • (4.1)
    it destroys a recursive_timed_mutex object owned by any thread, or
  • (4.2)
    a thread terminates while owning a recursive_timed_mutex object.

33.6.4.4 Shared mutex types [thread.sharedmutex.requirements]

33.6.4.4.1 General [thread.sharedmutex.requirements.general]

1
#
The standard library types shared_mutex and shared_timed_mutex are shared mutex types.
Shared mutex types meet the requirements of mutex types ([thread.mutex.requirements.mutex]) and additionally meet the requirements set out below.
In this description, m denotes an object of a shared mutex type.
[Note 1: 
The shared mutex types meet the Cpp17SharedLockable requirements ([thread.req.lockable.shared]).
— end note]
2
#
In addition to the exclusive lock ownership mode specified in [thread.mutex.requirements.mutex], shared mutex types provide a shared lock ownership mode.
Multiple execution agents can simultaneously hold a shared lock ownership of a shared mutex type.
But no execution agent holds a shared lock while another execution agent holds an exclusive lock on the same shared mutex type, and vice-versa.
The maximum number of execution agents which can share a shared lock on a single shared mutex type is unspecified, but is at least 10000.
If more than the maximum number of execution agents attempt to obtain a shared lock, the excess execution agents block until the number of shared locks are reduced below the maximum amount by other execution agents releasing their shared lock.
3
#
The expression m.lock_shared() is well-formed and has the following semantics:
4
#
Preconditions: The calling thread has no ownership of the mutex.
5
#
Effects: Blocks the calling thread until shared ownership of the mutex can be obtained for the calling thread.
If an exception is thrown then a shared lock has not been acquired for the current thread.
6
#
Synchronization: Prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.
7
#
Postconditions: The calling thread has a shared lock on the mutex.
8
#
Return type: void.
9
#
Throws: system_error when an exception is required ([thread.req.exception]).
10
#
Error conditions:
  • (10.1)
    operation_not_permitted — if the thread does not have the privilege to perform the operation.
  • (10.2)
    resource_deadlock_would_occur — if the implementation detects that a deadlock would occur.
11
#
The expression m.unlock_shared() is well-formed and has the following semantics:
12
#
Preconditions: The calling thread holds a shared lock on the mutex.
13
#
Effects: Releases a shared lock on the mutex held by the calling thread.
14
#
Return type: void.
15
#
Synchronization: This operation synchronizes with subsequent lock() operations that obtain ownership on the same object.
16
#
Throws: Nothing.
17
#
The expression m.try_lock_shared() is well-formed and has the following semantics:
18
#
Preconditions: The calling thread has no ownership of the mutex.
19
#
Effects: Attempts to obtain shared ownership of the mutex for the calling thread without blocking.
If shared ownership is not obtained, there is no effect and try_lock_shared() immediately returns.
An implementation may fail to obtain the lock even if it is not held by any other thread.
20
#
Synchronization: If try_lock_shared() returns true, prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.
21
#
Return type: bool.
22
#
Returns: true if the shared lock was acquired, otherwise false.
23
#
Throws: Nothing.

33.6.4.4.2 Class shared_mutex [thread.sharedmutex.class]

🔗
namespace std { class shared_mutex { public: shared_mutex(); ~shared_mutex(); shared_mutex(const shared_mutex&) = delete; shared_mutex& operator=(const shared_mutex&) = delete; // exclusive ownership void lock(); // blocking bool try_lock(); void unlock(); // shared ownership void lock_shared(); // blocking bool try_lock_shared(); void unlock_shared(); using native_handle_type = implementation-defined; // see [thread.req.native] native_handle_type native_handle(); // see [thread.req.native] }; }
1
#
The class shared_mutex provides a non-recursive mutex with shared ownership semantics.
2
#
The class shared_mutex meets all of the shared mutex requirements ([thread.sharedmutex.requirements]).
It is a standard-layout class ([class.prop]).
3
#
The behavior of a program is undefined if:
  • (3.1)
    it destroys a shared_mutex object owned by any thread,
  • (3.2)
    a thread attempts to recursively gain any ownership of a shared_mutex, or
  • (3.3)
    a thread terminates while possessing any ownership of a shared_mutex.
4
#
shared_mutex may be a synonym for shared_timed_mutex.

33.6.4.5 Shared timed mutex types [thread.sharedtimedmutex.requirements]

33.6.4.5.1 General [thread.sharedtimedmutex.requirements.general]

1
#
The standard library type shared_timed_mutex is a shared timed mutex type.
Shared timed mutex types meet the requirements of timed mutex types ([thread.timedmutex.requirements]), shared mutex types ([thread.sharedmutex.requirements]), and additionally meet the requirements set out below.
In this description, m denotes an object of a shared timed mutex type, rel_time denotes an object of an instantiation of duration ([time.duration]), and abs_time denotes an object of an instantiation of time_point.
[Note 1: 
The shared timed mutex types meet the Cpp17SharedTimedLockable requirements ([thread.req.lockable.shared.timed]).
— end note]
2
#
The expression m.try_lock_shared_for(rel_time) is well-formed and has the following semantics:
3
#
Preconditions: The calling thread has no ownership of the mutex.
4
#
Effects: Attempts to obtain shared lock ownership for the calling thread within the relative timeout ([thread.req.timing]) specified by rel_time.
If the time specified by rel_time is less than or equal to rel_time.zero(), the function attempts to obtain ownership without blocking (as if by calling try_lock_shared()).
The function returns within the timeout specified by rel_time only if it has obtained shared ownership of the mutex object.
[Note 2: 
As with try_lock(), there is no guarantee that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort to do so.
— end note]
If an exception is thrown then a shared lock has not been acquired for the current thread.
5
#
Synchronization: If try_lock_shared_for() returns true, prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.
6
#
Return type: bool.
7
#
Returns: true if the shared lock was acquired, otherwise false.
8
#
Throws: Timeout-related exceptions ([thread.req.timing]).
9
#
The expression m.try_lock_shared_until(abs_time) is well-formed and has the following semantics:
10
#
Preconditions: The calling thread has no ownership of the mutex.
11
#
Effects: The function attempts to obtain shared ownership of the mutex.
If abs_time has already passed, the function attempts to obtain shared ownership without blocking (as if by calling try_lock_shared()).
The function returns before the absolute timeout ([thread.req.timing]) specified by abs_time only if it has obtained shared ownership of the mutex object.
[Note 3: 
As with try_lock(), there is no guarantee that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort to do so.
— end note]
If an exception is thrown then a shared lock has not been acquired for the current thread.
12
#
Synchronization: If try_lock_shared_until() returns true, prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.
13
#
Return type: bool.
14
#
Returns: true if the shared lock was acquired, otherwise false.
15
#
Throws: Timeout-related exceptions ([thread.req.timing]).

33.6.4.5.2 Class shared_timed_mutex [thread.sharedtimedmutex.class]

🔗
namespace std { class shared_timed_mutex { public: shared_timed_mutex(); ~shared_timed_mutex(); shared_timed_mutex(const shared_timed_mutex&) = delete; shared_timed_mutex& operator=(const shared_timed_mutex&) = delete; // exclusive ownership void lock(); // blocking bool try_lock(); template<class Rep, class Period> bool try_lock_for(const chrono::duration<Rep, Period>& rel_time); template<class Clock, class Duration> bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time); void unlock(); // shared ownership void lock_shared(); // blocking bool try_lock_shared(); template<class Rep, class Period> bool try_lock_shared_for(const chrono::duration<Rep, Period>& rel_time); template<class Clock, class Duration> bool try_lock_shared_until(const chrono::time_point<Clock, Duration>& abs_time); void unlock_shared(); }; }
1
#
The class shared_timed_mutex provides a non-recursive mutex with shared ownership semantics.
2
#
The class shared_timed_mutex meets all of the shared timed mutex requirements ([thread.sharedtimedmutex.requirements]).
It is a standard-layout class ([class.prop]).
3
#
The behavior of a program is undefined if:
  • (3.1)
    it destroys a shared_timed_mutex object owned by any thread,
  • (3.2)
    a thread attempts to recursively gain any ownership of a shared_timed_mutex, or
  • (3.3)
    a thread terminates while possessing any ownership of a shared_timed_mutex.