tmp/tmp3p1dvy8r/{from.md → to.md}
RENAMED
|
@@ -24,11 +24,11 @@ The class `mutex` provides a non-recursive mutex with exclusive
|
|
| 24 |
ownership semantics. If one thread owns a mutex object, attempts by
|
| 25 |
another thread to acquire ownership of that object will fail (for
|
| 26 |
`try_lock()`) or block (for `lock()`) until the owning thread has
|
| 27 |
released ownership with a call to `unlock()`.
|
| 28 |
|
| 29 |
-
[*Note
|
| 30 |
it is possible for another thread `B` to lock the same mutex, observe
|
| 31 |
that it is no longer in use, unlock it, and destroy it, before thread
|
| 32 |
`A` appears to have returned from its unlock call. Implementations are
|
| 33 |
required to handle such scenarios correctly, as long as thread `A`
|
| 34 |
doesn’t access the mutex after the unlock call returns. These cases
|
|
@@ -37,11 +37,11 @@ used to protect the reference count. — *end note*]
|
|
| 37 |
|
| 38 |
The class `mutex` meets all of the mutex requirements
|
| 39 |
[[thread.mutex.requirements]]. It is a standard-layout class
|
| 40 |
[[class.prop]].
|
| 41 |
|
| 42 |
-
[*Note
|
| 43 |
object calls `lock()` on that object. If the implementation can detect
|
| 44 |
the deadlock, a `resource_deadlock_would_occur` error condition might be
|
| 45 |
observed. — *end note*]
|
| 46 |
|
| 47 |
The behavior of a program is undefined if it destroys a `mutex` object
|
|
|
|
| 24 |
ownership semantics. If one thread owns a mutex object, attempts by
|
| 25 |
another thread to acquire ownership of that object will fail (for
|
| 26 |
`try_lock()`) or block (for `lock()`) until the owning thread has
|
| 27 |
released ownership with a call to `unlock()`.
|
| 28 |
|
| 29 |
+
[*Note 4*: After a thread `A` has called `unlock()`, releasing a mutex,
|
| 30 |
it is possible for another thread `B` to lock the same mutex, observe
|
| 31 |
that it is no longer in use, unlock it, and destroy it, before thread
|
| 32 |
`A` appears to have returned from its unlock call. Implementations are
|
| 33 |
required to handle such scenarios correctly, as long as thread `A`
|
| 34 |
doesn’t access the mutex after the unlock call returns. These cases
|
|
|
|
| 37 |
|
| 38 |
The class `mutex` meets all of the mutex requirements
|
| 39 |
[[thread.mutex.requirements]]. It is a standard-layout class
|
| 40 |
[[class.prop]].
|
| 41 |
|
| 42 |
+
[*Note 5*: A program can deadlock if the thread that owns a `mutex`
|
| 43 |
object calls `lock()` on that object. If the implementation can detect
|
| 44 |
the deadlock, a `resource_deadlock_would_occur` error condition might be
|
| 45 |
observed. — *end note*]
|
| 46 |
|
| 47 |
The behavior of a program is undefined if it destroys a `mutex` object
|