[thread.timedmutex.requirements]

Files changed (1) hide show

tmp/tmpxk2bmx1u/{from.md → to.md} +41 -41

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

@@ -1,55 +1,55 @@
 #### 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*]
@@ -58,13 +58,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 {
@@ -82,12 +82,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
@@ -96,13 +96,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()`,
@@ -128,12 +128,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
@@ -142,26 +142,26 @@ 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.

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

Diff to HTML by rtfpessoa