[thread.mutex.requirements.mutex]

Files changed (1) hide show

tmp/tmp5ootk66j/{from.md → to.md} +19 -18

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

@@ -1,15 +1,17 @@
 #### 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.
@@ -27,15 +29,15 @@ functions of the mutex types are as follows:
 The implementation provides lock and unlock operations, as described
 below. For purposes of determining the existence of a data race, these
 behave as atomic operations [[intro.multithread]]. The lock and unlock
 operations on a single mutex appears to occur in a single total order.
-[*Note 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:
@@ -45,17 +47,17 @@ semantics:
 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:*
@@ -81,24 +83,23 @@ 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:
@@ -140,11 +141,11 @@ 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()`.
-[*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
@@ -153,11 +154,11 @@ 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

 #### Mutex types <a id="thread.mutex.requirements.mutex">[[thread.mutex.requirements.mutex]]</a>
+##### General <a id="thread.mutex.requirements.mutex.general">[[thread.mutex.requirements.mutex.general]]</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 [[thread.mutex.requirements.mutex]]. In this description, `m`
+denotes an object of a mutex type.
+[*Note 1*: The mutex types meet the *Cpp17Lockable* requirements
+[[thread.req.lockable.req]]. — *end note*]
 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 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 2*: This can be viewed as the modification order
 [[intro.multithread]] of the mutex. — *end note*]
+[*Note 3*: Construction and destruction of an object of a mutex type
+need not be thread-safe; other synchronization can be used to ensure
 that mutex objects are initialized and visible to other
 threads. — *end note*]
 The expression `m.lock()` is well-formed and has the following
 semantics:
 the mutex.
 *Effects:* Blocks the calling thread until ownership of the mutex can be
 obtained for the calling thread.
 *Synchronization:* Prior `unlock()` operations on the same object
 *synchronize with*[[intro.multithread]] this operation.
+*Ensures:* The calling thread owns the mutex.
+*Return type:* `void`.
 *Throws:* `system_error` when an exception is
 required [[thread.req.exception]].
 *Error conditions:*
 exchange [[atomics]]. — *end note*]
 An implementation should ensure that `try_lock()` does not consistently
 return `false` in the absence of contending mutex acquisitions.
 *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*]
+*Return type:* `bool`.
+*Returns:* `true` if ownership was obtained, otherwise `false`.
 *Throws:* Nothing.
 The expression `m.unlock()` is well-formed and has the following
 semantics:
 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 4*: 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
 The class `mutex` meets all of the mutex requirements
 [[thread.mutex.requirements]]. It is a standard-layout class
 [[class.prop]].
+[*Note 5*: 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

Diff to HTML by rtfpessoa