[thread.sharedmutex.requirements.general] (original) (raw)

32 Concurrency support library [thread]

32.6 Mutual exclusion [thread.mutex]

32.6.4 Mutex requirements [thread.mutex.requirements]

32.6.4.4 Shared mutex types [thread.sharedmutex.requirements]

32.6.4.4.1 General [thread.sharedmutex.requirements.general]

The standard library types shared_mutex and shared_timed_mutexare 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.

In addition to the exclusive lock ownership mode specified in [thread.mutex.requirements.mutex], shared mutex types provide ashared 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.

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

Preconditions: The calling thread has no ownership of the mutex.

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.

Synchronization: Prior unlock() operations on the same object synchronize with ([intro.multithread]) this operation.

Postconditions: The calling thread has a shared lock on the mutex.

Error conditions:

• operation_not_permitted — if the thread does not have the privilege to perform the operation.
• resource_deadlock_would_occur — if the implementation detects that a deadlock would occur.

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

Preconditions: The calling thread holds a shared lock on the mutex.

Effects: Releases a shared lock on the mutex held by the calling thread.

Synchronization: This operation synchronizes with subsequentlock() operations that obtain ownership on the same object.

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

Preconditions: The calling thread has no ownership of the mutex.

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.

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

Returns: true if the shared lock was acquired, otherwise false.