[thread.mutex.requirements] (original) (raw)

32 Concurrency support library [thread]

32.6 Mutual exclusion [thread.mutex]

32.6.4 Mutex requirements [thread.mutex.requirements]

32.6.4.1 General [thread.mutex.requirements.general]

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

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

32.6.4.2.2 Class mutex [thread.mutex.class]

32.6.4.2.3 Class recursive_mutex [thread.mutex.recursive]

32.6.4.3 Timed mutex types [thread.timedmutex.requirements]

32.6.4.3.1 General [thread.timedmutex.requirements.general]

32.6.4.3.2 Class timed_mutex [thread.timedmutex.class]

32.6.4.3.3 Class recursive_timed_mutex [thread.timedmutex.recursive]

32.6.4.4 Shared mutex types [thread.sharedmutex.requirements]

32.6.4.4.1 General [thread.sharedmutex.requirements.general]

32.6.4.4.2 Class shared_mutex [thread.sharedmutex.class]

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

32.6.4.5.1 General [thread.sharedtimedmutex.requirements.general]

32.6.4.5.2 Class shared_timed_mutex [thread.sharedtimedmutex.class]

32.6.4.1 General [thread.mutex.requirements.general]

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.

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

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

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.

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.

The error conditions for error codes, if any, reported by member functions of the mutex types are as follows:

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 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_]

The expression m.lock() is well-formed and has the following semantics:

Preconditions: If m is of type mutex, timed_mutex,shared_mutex, or shared_timed_mutex, the calling thread does not own the mutex.

Effects: Blocks the calling thread until ownership of the mutex can be obtained for the calling thread.

Postconditions: The calling thread owns the mutex.

Error conditions:

The expression m.try_lock() is well-formed and has the following semantics:

Preconditions: If m is of type mutex, timed_mutex,shared_mutex, or shared_timed_mutex, the calling thread does not own the mutex.

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 falsein the absence of contending mutex acquisitions.

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 subsequenttry_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_]

Returns: true if ownership was obtained, otherwise false.

The expression m.unlock() is well-formed and has the following semantics:

Preconditions: The calling thread owns the mutex.

Effects: Releases the calling thread's ownership of the mutex.

Synchronization: This operation synchronizes with subsequent lock operations that obtain ownership on the same object.

32.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; native_handle_type native_handle(); };}

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 (forlock()) until the owning thread has released ownership with a call tounlock().

[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.

Conforming implementations handle such scenarios correctly, as long as thread A does not 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]).

[Note 2:

A program can deadlock if the thread that owns a mutex object callslock() 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.

32.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; native_handle_type native_handle(); };}

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.

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

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_mutexobject, additional calls to try_lock() fail, and additional calls tolock() throw an exception of type system_error.

A thread shall call unlock() once for each level of ownership acquired by calls tolock() and try_lock().

Only when all levels of ownership have been released may ownership be acquired by another thread.

The behavior of a program is undefined if

32.6.4.3 Timed mutex types [thread.timedmutex.requirements]

32.6.4.3.1 General [thread.timedmutex.requirements.general]

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.

The expression m.try_lock_for(rel_time) is well-formed and has the following semantics:

Preconditions: If m is of type timed_mutex orshared_timed_mutex, the calling thread does not own the mutex.

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 callingtry_lock()).

The function returns within the timeout specified byrel_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_]

Synchronization: If try_lock_for() returns true, prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.

Returns: true if ownership was obtained, otherwise false.

The expression m.try_lock_until(abs_time) is well-formed and has the following semantics:

Preconditions: If m is of type timed_mutex orshared_timed_mutex, the calling thread does not own the mutex.

Effects: The function attempts to obtain ownership of the mutex.

Ifabs_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 byabs_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_]

Synchronization: If try_lock_until() returns true, prior unlock()operations on the same object synchronize with ([intro.multithread]) this operation.

Returns: true if ownership was obtained, otherwise false.

32.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(); 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; native_handle_type native_handle(); };}

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).

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

The behavior of a program is undefined if

32.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(); 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; native_handle_type native_handle(); };}

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 (fortry_lock()) or block (for lock(), try_lock_for(), andtry_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).

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

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 arecursive_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(), andtry_lock_until().

Only when all levels of ownership have been released may ownership of the object be acquired by another thread.

The behavior of a program is undefined if

32.6.4.4 Shared mutex types [thread.sharedmutex.requirements]

32.6.4.4.1 General [thread.sharedmutex.requirements.general]

32.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;void lock(); bool try_lock();void unlock();void lock_shared(); bool try_lock_shared();void unlock_shared();using native_handle_type = implementation-defined; native_handle_type native_handle(); };}

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

32.6.4.5.1 General [thread.sharedtimedmutex.requirements.general]

32.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;void lock(); 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();void lock_shared(); 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();};}