[thread.mutex.requirements]

Files changed (1) hide show

tmp/tmpgs3vzpek/{from.md → to.md} +165 -166

tmp/tmpgs3vzpek/{from.md → to.md} RENAMED Viewed

@@ -1,128 +1,129 @@
 ### Mutex requirements <a id="thread.mutex.requirements">[[thread.mutex.requirements]]</a>
 #### In general <a id="thread.mutex.requirements.general">[[thread.mutex.requirements.general]]</a>
 A mutex object facilitates protection against data races and allows safe
-synchronization of data between execution agents (
-[[thread.req.lockable]]). 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.
 #### Mutex types <a id="thread.mutex.requirements.mutex">[[thread.mutex.requirements.mutex]]</a>
 The *mutex types* are the standard library types `mutex`,
 `recursive_mutex`, `timed_mutex`, `recursive_timed_mutex`,
-`shared_mutex`, and `shared_timed_mutex`. They shall meet the
-requirements set out in this section. In this description, `m` denotes
-an object of a mutex type.
-The mutex types shall meet the `Lockable` requirements (
-[[thread.req.lockable.req]]).
-The mutex types shall be `DefaultConstructible` and `Destructible`. If
-initialization of an object of a mutex type fails, an exception of type
-`system_error` shall be thrown. The mutex types shall not be copyable or
-movable.
 The error conditions for error codes, if any, reported by member
-functions of the mutex types shall be:
 - `resource_unavailable_try_again` — if any native handle type
   manipulated is not available.
 - `operation_not_permitted` — if the thread does not have the privilege
   to perform the operation.
 - `invalid_argument` — if any native handle type manipulated as part of
   mutex construction is incorrect.
-The implementation shall provide 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 shall appear to occur in a
-single total order.
-[*Note 1*: This can be viewed as the modification order (
-[[intro.multithread]]) of the mutex. — *end note*]
 [*Note 2*: Construction and destruction of an object of a mutex type
 need not be thread-safe; other synchronization should be used to ensure
 that mutex objects are initialized and visible to other
 threads. — *end note*]
-The expression `m.lock()` shall be well-formed and have the following
 semantics:
-*Requires:* 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.
 *Return type:* `void`.
-*Synchronization:* Prior `unlock()` operations on the same object shall
-*synchronize with* ([[intro.multithread]]) this operation.
 *Throws:* `system_error` when an exception is
-required ([[thread.req.exception]]).
 *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.try_lock()` shall be well-formed and have the
-following semantics:
-*Requires:* 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 1*: This spurious failure is normally uncommon, but allows
-interesting implementations based on a simple compare and exchange
-(Clause  [[atomics]]). — *end note*]
 An implementation should ensure that `try_lock()` does not consistently
 return `false` in the absence of contending mutex acquisitions.
 *Return type:* `bool`.
 *Returns:* `true` if ownership of the mutex was obtained for the calling
 thread, otherwise `false`.
 *Synchronization:* If `try_lock()` returns `true`, prior `unlock()`
-operations on the same object *synchronize
-with* ([[intro.multithread]]) this operation.
 [*Note 2*: 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*]
 *Throws:* Nothing.
-The expression `m.unlock()` shall be well-formed and have the following
 semantics:
-*Requires:* The calling thread shall own the mutex.
 *Effects:* Releases the calling thread’s ownership of the mutex.
 *Return type:* `void`.
 *Synchronization:* This operation synchronizes
-with ([[intro.multithread]]) subsequent lock operations that obtain
 ownership on the same object.
 *Throws:* Nothing.
 ##### Class `mutex` <a id="thread.mutex.class">[[thread.mutex.class]]</a>
@@ -139,12 +140,12 @@ namespace std {
     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
@@ -160,17 +161,17 @@ that it is no longer in use, unlock it, and destroy it, before thread
 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` shall satisfy all of the mutex requirements (
-[[thread.mutex.requirements]]). It shall be a standard-layout class
-(Clause  [[class]]).
-[*Note 4*: A program may 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 may 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.
@@ -189,92 +190,92 @@ namespace std {
     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]
   };
 }
 ```
 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` shall satisfy all of the mutex
-requirements ([[thread.mutex.requirements]]). It shall be a
-standard-layout class (Clause  [[class]]).
 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()` shall fail, and additional calls to `lock()` shall 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.
 The behavior of a program is undefined if:
 - it destroys a `recursive_mutex` object owned by any thread or
 - a thread terminates while owning a `recursive_mutex` object.
 #### Timed mutex types <a id="thread.timedmutex.requirements">[[thread.timedmutex.requirements]]</a>
 The *timed mutex types* are the standard library types `timed_mutex`,
-`recursive_timed_mutex`, and `shared_timed_mutex`. They shall 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` ([[time.duration]]), and `abs_time` denotes an object of an
-instantiation of `time_point` ([[time.point]]).
-The timed mutex types shall meet the `TimedLockable` requirements (
-[[thread.req.lockable.timed]]).
-The expression `m.try_lock_for(rel_time)` shall be well-formed and have
-the following semantics:
-*Requires:* If `m` is of type `timed_mutex` or `shared_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 calling `try_lock()`). The function shall return
-within the timeout specified by `rel_time` only if it has obtained
-ownership of the mutex object.
 [*Note 1*: 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*]
 *Return type:* `bool`.
 *Returns:* `true` if ownership was obtained, otherwise `false`.
 *Synchronization:* If `try_lock_for()` returns `true`, prior `unlock()`
-operations on the same object *synchronize
-with* ([[intro.multithread]]) this operation.
-*Throws:* Timeout-related exceptions ([[thread.req.timing]]).
-The expression `m.try_lock_until(abs_time)` shall be well-formed and
-have the following semantics:
-*Requires:* If `m` is of type `timed_mutex` or `shared_timed_mutex`, the
-calling thread does not own the mutex.
 *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 shall
-return before the absolute timeout ([[thread.req.timing]]) specified by
 `abs_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*]
@@ -283,13 +284,13 @@ expected to make a strong effort to do so. — *end note*]
 *Returns:* `true` if ownership was obtained, otherwise `false`.
 *Synchronization:* If `try_lock_until()` returns `true`, prior
 `unlock()` operations on the same object *synchronize
-with* ([[intro.multithread]]) this operation.
-*Throws:* Timeout-related exceptions ([[thread.req.timing]]).
 ##### Class `timed_mutex` <a id="thread.timedmutex.class">[[thread.timedmutex.class]]</a>
 ``` cpp
 namespace std {
@@ -307,12 +308,12 @@ namespace std {
       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]
   };
 }
 ```
 The class `timed_mutex` provides a non-recursive mutex with exclusive
@@ -321,13 +322,13 @@ 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` shall satisfy all of the timed mutex
-requirements ([[thread.timedmutex.requirements]]). It shall be a
-standard-layout class (Clause  [[class]]).
 The behavior of a program is undefined if:
 - it destroys a `timed_mutex` object owned by any thread,
 - a thread that owns a `timed_mutex` object calls `lock()`,
@@ -353,12 +354,12 @@ namespace std {
       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]
   };
 }
 ```
 The class `recursive_timed_mutex` provides a recursive mutex with
@@ -367,99 +368,99 @@ exclusive ownership semantics. If one thread owns a
 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).
-The class `recursive_timed_mutex` shall satisfy all of the timed mutex
-requirements ([[thread.timedmutex.requirements]]). It shall be a
-standard-layout class (Clause  [[class]]).
 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()` shall fail, and additional calls
-to `lock()` shall 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.
 The behavior of a program is undefined if:
 - it destroys a `recursive_timed_mutex` object owned by any thread, or
 - a thread terminates while owning a `recursive_timed_mutex` object.
 #### Shared mutex types <a id="thread.sharedmutex.requirements">[[thread.sharedmutex.requirements]]</a>
 The standard library types `shared_mutex` and `shared_timed_mutex` are
-*shared mutex types*. Shared mutex types shall meet the requirements of
-mutex types ([[thread.mutex.requirements.mutex]]), and additionally
-shall 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 a
 *shared lock* ownership mode. Multiple execution agents can
 simultaneously hold a shared lock ownership of a shared mutex type. But
-no execution agent shall hold 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 shall be
-at least 10000. If more than the maximum number of execution agents
-attempt to obtain a shared lock, the excess execution agents shall 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()` shall be well-formed and have the
-following semantics:
-*Requires:* 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 shall not have been acquired for the current thread.
-*Postconditions:* The calling thread has a shared lock on the mutex.
 *Return type:* `void`.
-*Synchronization:* Prior `unlock()` operations on the same object shall
-synchronize with ([[intro.multithread]]) this operation.
 *Throws:* `system_error` when an exception is
-required ([[thread.req.exception]]).
 *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()` shall be well-formed and have the
-following semantics:
-*Requires:* The calling thread shall hold a shared lock on the mutex.
 *Effects:* Releases a shared lock on the mutex held by the calling
 thread.
 *Return type:* `void`.
 *Synchronization:* This operation synchronizes
-with ([[intro.multithread]]) subsequent `lock()` operations that obtain
 ownership on the same object.
 *Throws:* Nothing.
-The expression `m.try_lock_shared()` shall be well-formed and have the
 following semantics:
-*Requires:* 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
@@ -470,15 +471,15 @@ other thread.
 *Returns:* `true` if the shared ownership lock was acquired, `false`
 otherwise.
 *Synchronization:* If `try_lock_shared()` returns `true`, prior
 `unlock()` operations on the same object synchronize
-with ([[intro.multithread]]) this operation.
 *Throws:* Nothing.
-##### Class shared_mutex <a id="thread.sharedmutex.class">[[thread.sharedmutex.class]]</a>
 ``` cpp
 namespace std {
   class shared_mutex {
   public:
@@ -486,32 +487,32 @@ namespace std {
     ~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]
   };
 }
 ```
 The class `shared_mutex` provides a non-recursive mutex with shared
 ownership semantics.
-The class `shared_mutex` shall satisfy all of the shared mutex
-requirements ([[thread.sharedmutex.requirements]]). It shall be a
-standard-layout class (Clause  [[class]]).
 The behavior of a program is undefined if:
 - it destroys a `shared_mutex` object owned by any thread,
 - a thread attempts to recursively gain any ownership of a
@@ -522,76 +523,76 @@ The behavior of a program is undefined if:
 `shared_mutex` may be a synonym for `shared_timed_mutex`.
 #### Shared timed mutex types <a id="thread.sharedtimedmutex.requirements">[[thread.sharedtimedmutex.requirements]]</a>
 The standard library type `shared_timed_mutex` is a *shared timed mutex
-type*. Shared timed mutex types shall meet the requirements of timed
-mutex types ([[thread.timedmutex.requirements]]), shared mutex types (
-[[thread.sharedmutex.requirements]]), and additionally shall meet the
 requirements set out below. In this description, `m` denotes an object
 of a shared timed mutex type, `rel_type` denotes an object of an
-instantiation of `duration` ([[time.duration]]), and `abs_time` denotes
-an object of an instantiation of `time_point` ([[time.point]]).
-The expression `m.try_lock_shared_for(rel_time)` shall be well-formed
-and have the following semantics:
-*Requires:* The calling thread has no ownership of the mutex.
 *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 shall
-return within the timeout specified by `rel_time` only if it has
-obtained shared ownership of the mutex object.
 [*Note 1*: 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 shall not have been
-acquired for the current thread.
 *Return type:* `bool`.
 *Returns:* `true` if the shared lock was acquired, `false` otherwise.
 *Synchronization:* If `try_lock_shared_for()` returns `true`, prior
 `unlock()` operations on the same object synchronize
-with ([[intro.multithread]]) this operation.
-*Throws:* Timeout-related exceptions ([[thread.req.timing]]).
-The expression `m.try_lock_shared_until(abs_time)` shall be well-formed
-and have the following semantics:
-*Requires:* The calling thread has no ownership of the mutex.
 *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 shall return before the absolute
-timeout ([[thread.req.timing]]) specified by `abs_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 shall not have been
-acquired for the current thread.
 *Return type:* `bool`.
 *Returns:* `true` if the shared lock was acquired, `false` otherwise.
 *Synchronization:* If `try_lock_shared_until()` returns `true`, prior
 `unlock()` operations on the same object synchronize
-with ([[intro.multithread]]) this operation.
-*Throws:* Timeout-related exceptions ([[thread.req.timing]]).
 ##### Class `shared_timed_mutex` <a id="thread.sharedtimedmutex.class">[[thread.sharedtimedmutex.class]]</a>
 ``` cpp
 namespace std {
@@ -601,39 +602,37 @@ namespace std {
     ~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();
   };
 }
 ```
 The class `shared_timed_mutex` provides a non-recursive mutex with
 shared ownership semantics.
-The class `shared_timed_mutex` shall satisfy all of the shared timed
-mutex requirements ([[thread.sharedtimedmutex.requirements]]). It shall
-be a standard-layout class (Clause  [[class]]).
 The behavior of a program is undefined if:
 - it destroys a `shared_timed_mutex` object owned by any thread,
 - a thread attempts to recursively gain any ownership of a

 ### Mutex requirements <a id="thread.mutex.requirements">[[thread.mutex.requirements]]</a>
 #### In general <a id="thread.mutex.requirements.general">[[thread.mutex.requirements.general]]</a>
 A mutex object facilitates protection against data races and allows safe
+synchronization of data between execution agents
+[[thread.req.lockable]]. 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.
 #### Mutex types <a id="thread.mutex.requirements.mutex">[[thread.mutex.requirements.mutex]]</a>
 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 this subclause. In this description, `m` denotes an object of a
+mutex type.
+The mutex types meet the *Cpp17Lockable* requirements
+[[thread.req.lockable.req]].
+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.
 The error conditions for error codes, if any, reported by member
+functions of the mutex types are as follows:
 - `resource_unavailable_try_again` — if any native handle type
   manipulated is not available.
 - `operation_not_permitted` — if the thread does not have the privilege
   to perform the operation.
 - `invalid_argument` — if any native handle type manipulated as part of
   mutex construction is incorrect.
+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 1*: This can be viewed as the modification order
+[[intro.multithread]] of the mutex. — *end note*]
 [*Note 2*: Construction and destruction of an object of a mutex type
 need not be thread-safe; other synchronization should 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.
+*Ensures:* The calling thread owns the mutex.
 *Return type:* `void`.
+*Synchronization:* Prior `unlock()` operations on the same object
+*synchronize with*[[intro.multithread]] this operation.
 *Throws:* `system_error` when an exception is
+required [[thread.req.exception]].
 *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.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 1*: 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.
 *Return type:* `bool`.
 *Returns:* `true` if ownership of the mutex was obtained for the calling
 thread, otherwise `false`.
 *Synchronization:* If `try_lock()` returns `true`, prior `unlock()`
+operations on the same object *synchronize with*[[intro.multithread]]
+this operation.
 [*Note 2*: 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*]
 *Throws:* Nothing.
+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.
 *Return type:* `void`.
 *Synchronization:* This operation synchronizes
+with [[intro.multithread]] subsequent lock operations that obtain
 ownership on the same object.
 *Throws:* Nothing.
 ##### Class `mutex` <a id="thread.mutex.class">[[thread.mutex.class]]</a>
     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
 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 4*: 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.
     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]
   };
 }
 ```
 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]]. It is a standard-layout class
+[[class.prop]].
 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.
 The behavior of a program is undefined if:
 - it destroys a `recursive_mutex` object owned by any thread or
 - a thread terminates while owning a `recursive_mutex` object.
 #### Timed mutex types <a id="thread.timedmutex.requirements">[[thread.timedmutex.requirements]]</a>
 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` [[time.duration]], and `abs_time` denotes an object of an
+instantiation of `time_point` [[time.point]].
+The timed mutex types meet the *Cpp17TimedLockable* requirements
+[[thread.req.lockable.timed]].
+The expression `m.try_lock_for(rel_time)` is well-formed and has the
+following semantics:
+*Preconditions:* If `m` is of type `timed_mutex` or
+`shared_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 calling `try_lock()`). The function returns within
+the timeout specified by `rel_time` only if it has obtained ownership of
+the mutex object.
 [*Note 1*: 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*]
 *Return type:* `bool`.
 *Returns:* `true` if ownership was obtained, otherwise `false`.
 *Synchronization:* If `try_lock_for()` returns `true`, prior `unlock()`
+operations on the same object *synchronize with*[[intro.multithread]]
+this operation.
+*Throws:* Timeout-related exceptions [[thread.req.timing]].
+The expression `m.try_lock_until(abs_time)` is well-formed and has the
+following semantics:
+*Preconditions:* If `m` is of type `timed_mutex` or
+`shared_timed_mutex`, the calling thread does not own the mutex.
 *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 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*]
 *Returns:* `true` if ownership was obtained, otherwise `false`.
 *Synchronization:* If `try_lock_until()` returns `true`, prior
 `unlock()` operations on the same object *synchronize
+with*[[intro.multithread]] this operation.
+*Throws:* Timeout-related exceptions [[thread.req.timing]].
 ##### Class `timed_mutex` <a id="thread.timedmutex.class">[[thread.timedmutex.class]]</a>
 ``` cpp
 namespace std {
       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]
   };
 }
 ```
 The class `timed_mutex` provides a non-recursive mutex with exclusive
 `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]]. It is a standard-layout class
+[[class.prop]].
 The behavior of a program is undefined if:
 - it destroys a `timed_mutex` object owned by any thread,
 - a thread that owns a `timed_mutex` object calls `lock()`,
       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]
   };
 }
 ```
 The class `recursive_timed_mutex` provides a recursive mutex with
 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).
+The class `recursive_timed_mutex` meets all of the timed mutex
+requirements [[thread.timedmutex.requirements]]. It is a standard-layout
+class [[class.prop]].
 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.
 The behavior of a program is undefined if:
 - it destroys a `recursive_timed_mutex` object owned by any thread, or
 - a thread terminates while owning a `recursive_timed_mutex` object.
 #### Shared mutex types <a id="thread.sharedmutex.requirements">[[thread.sharedmutex.requirements]]</a>
 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.
 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.
+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.
+*Ensures:* The calling thread has a shared lock on the mutex.
 *Return type:* `void`.
+*Synchronization:* Prior `unlock()` operations on the same object
+synchronize with [[intro.multithread]] this operation.
 *Throws:* `system_error` when an exception is
+required [[thread.req.exception]].
 *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.
 *Return type:* `void`.
 *Synchronization:* This operation synchronizes
+with [[intro.multithread]] subsequent `lock()` operations that obtain
 ownership on the same object.
 *Throws:* Nothing.
+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
 *Returns:* `true` if the shared ownership lock was acquired, `false`
 otherwise.
 *Synchronization:* If `try_lock_shared()` returns `true`, prior
 `unlock()` operations on the same object synchronize
+with [[intro.multithread]] this operation.
 *Throws:* Nothing.
+##### Class `shared_mutex` <a id="thread.sharedmutex.class">[[thread.sharedmutex.class]]</a>
 ``` cpp
 namespace std {
   class shared_mutex {
   public:
     ~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]
   };
 }
 ```
 The class `shared_mutex` provides a non-recursive mutex with shared
 ownership semantics.
+The class `shared_mutex` meets all of the shared mutex requirements
+[[thread.sharedmutex.requirements]]. It is a standard-layout class
+[[class.prop]].
 The behavior of a program is undefined if:
 - it destroys a `shared_mutex` object owned by any thread,
 - a thread attempts to recursively gain any ownership of a
 `shared_mutex` may be a synonym for `shared_timed_mutex`.
 #### Shared timed mutex types <a id="thread.sharedtimedmutex.requirements">[[thread.sharedtimedmutex.requirements]]</a>
 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_type` denotes an object of an
+instantiation of `duration` [[time.duration]], and `abs_time` denotes an
+object of an instantiation of `time_point` [[time.point]].
+The expression `m.try_lock_shared_for(rel_time)` is well-formed and has
+the following semantics:
+*Preconditions:* The calling thread has no ownership of the mutex.
 *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 1*: 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.
 *Return type:* `bool`.
 *Returns:* `true` if the shared lock was acquired, `false` otherwise.
 *Synchronization:* If `try_lock_shared_for()` returns `true`, prior
 `unlock()` operations on the same object synchronize
+with [[intro.multithread]] this operation.
+*Throws:* Timeout-related exceptions [[thread.req.timing]].
+The expression `m.try_lock_shared_until(abs_time)` is well-formed and
+has the following semantics:
+*Preconditions:* The calling thread has no ownership of the mutex.
 *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 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.
 *Return type:* `bool`.
 *Returns:* `true` if the shared lock was acquired, `false` otherwise.
 *Synchronization:* If `try_lock_shared_until()` returns `true`, prior
 `unlock()` operations on the same object synchronize
+with [[intro.multithread]] this operation.
+*Throws:* Timeout-related exceptions [[thread.req.timing]].
 ##### Class `shared_timed_mutex` <a id="thread.sharedtimedmutex.class">[[thread.sharedtimedmutex.class]]</a>
 ``` cpp
 namespace std {
     ~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();
   };
 }
 ```
 The class `shared_timed_mutex` provides a non-recursive mutex with
 shared ownership semantics.
+The class `shared_timed_mutex` meets all of the shared timed mutex
+requirements [[thread.sharedtimedmutex.requirements]]. It is a
+standard-layout class [[class.prop]].
 The behavior of a program is undefined if:
 - it destroys a `shared_timed_mutex` object owned by any thread,
 - a thread attempts to recursively gain any ownership of a

Diff to HTML by rtfpessoa