[thread.mutex.requirements]

Files changed (1) hide show

tmp/tmp1m8hwszj/{from.md → to.md} +161 -98

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

@@ -10,15 +10,15 @@ 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 `std::mutex`,
-`std::recursive_mutex`, `std::timed_mutex`,
-`std::recursive_timed_mutex`, and `std::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
@@ -31,37 +31,39 @@ 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.
-- `device_or_resource_busy` — if any native handle type manipulated is
-  already locked.
 - `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. this can be viewed as the modification order (
-[[intro.multithread]]) of the mutex. 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.
 The expression `m.lock()` shall be well-formed and have the following
 semantics:
-*Requires:* If `m` is of type `std::mutex`, `std::timed_mutex`, or
-`std::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.
-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
@@ -71,51 +73,53 @@ required ([[thread.req.exception]]).
 - `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.
-- `device_or_resource_busy` — if the mutex is already locked and
-  blocking is not possible.
 The expression `m.try_lock()` shall be well-formed and have the
 following semantics:
-*Requires:* If `m` is of type `std::mutex`, `std::timed_mutex`, or
-`std::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. This
-spurious failure is normally uncommon, but allows interesting
-implementations based on a simple compare and exchange
-(Clause  [[atomics]]). 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. 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.
 *Throws:* Nothing.
 The expression `m.unlock()` shall be well-formed and have the following
 semantics:
-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.
@@ -135,11 +139,11 @@ namespace std {
     void lock();
     bool try_lock();
     void unlock();
- typedef implementation-defined native_handle_type; // See~[thread.req.native]
     native_handle_type native_handle();                // See~[thread.req.native]
   };
 }
 ```
@@ -147,26 +151,27 @@ 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()`.
-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.
-The class `mutex` shall satisfy all the `Mutex` requirements (
 [[thread.mutex.requirements]]). It shall be a standard-layout class
 (Clause  [[class]]).
-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.
 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.
@@ -184,11 +189,11 @@ namespace std {
     void lock();
     bool try_lock() noexcept;
     void unlock();
- typedef implementation-defined native_handle_type; // See~[thread.req.native]
     native_handle_type native_handle();                // See~[thread.req.native]
   };
 }
 ```
@@ -196,13 +201,13 @@ 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 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
@@ -218,38 +223,39 @@ 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
-`std::timed_mutex`, `std::recursive_timed_mutex`, and
-`std::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:
-If `m` is of type `std::timed_mutex` or `std::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. 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.
-*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
@@ -258,23 +264,24 @@ 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 `std::timed_mutex` or
-`std::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. 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.
-*Return type:* `bool`
 *Returns:* `true` if ownership was obtained, otherwise `false`.
 *Synchronization:* If `try_lock_until()` returns `true`, prior
 `unlock()` operations on the same object *synchronize
@@ -300,11 +307,11 @@ 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();
- typedef implementation-defined native_handle_type; // See~[thread.req.native]
     native_handle_type native_handle();                // See~[thread.req.native]
   };
 }
 ```
@@ -314,11 +321,11 @@ 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 `TimedMutex`
 requirements ([[thread.timedmutex.requirements]]). It shall be a
 standard-layout class (Clause  [[class]]).
 The behavior of a program is undefined if:
@@ -346,11 +353,11 @@ 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();
- typedef implementation-defined native_handle_type; // See~[thread.req.native]
     native_handle_type native_handle();                // See~[thread.req.native]
   };
 }
 ```
@@ -360,11 +367,11 @@ 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 `TimedMutex`
 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()`,
@@ -382,20 +389,17 @@ 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 timed mutex types <a id="thread.sharedtimedmutex.requirements">[[thread.sharedtimedmutex.requirements]]</a>
-The standard library type `std::shared_timed_mutex` is a *shared timed
-mutex type*. Shared timed mutex types shall meet the requirements of
-timed mutex types ([[thread.timedmutex.requirements]]), and
-additionally shall meet the requirements set out below. In this
-description, `m` denotes an object of a 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]]).
 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
@@ -415,28 +419,26 @@ following semantics:
 *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.
-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.
-- `device_or_resource_busy` — if the mutex is already locked and
-  blocking is not possible.
 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.
@@ -467,15 +469,71 @@ 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.
 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.
@@ -483,14 +541,17 @@ and have the following semantics:
 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. 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. 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.
@@ -509,14 +570,17 @@ and have the following semantics:
 *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. 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. 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.
@@ -563,14 +627,13 @@ namespace std {
 ```
 The class `shared_timed_mutex` provides a non-recursive mutex with
 shared ownership semantics.
-The class `shared_timed_mutex` shall satisfy all of the
-`SharedTimedMutex` 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

 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
 - `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
 - `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.
     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]
   };
 }
 ```
 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 3*: 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` 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.
     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]
   };
 }
 ```
 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
 - 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
 *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*]
+*Return type:* `bool`.
 *Returns:* `true` if ownership was obtained, otherwise `false`.
 *Synchronization:* If `try_lock_until()` returns `true`, prior
 `unlock()` operations on the same object *synchronize
       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]
   };
 }
 ```
 `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:
       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]
   };
 }
 ```
 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()`,
 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
 *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.
 *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();
+    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
+  `shared_mutex`, or
+- a thread terminates while possessing any ownership of a
+  `shared_mutex`.
+`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.
 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.
 *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.
 ```
 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

Diff to HTML by rtfpessoa