tmp/tmpopl553fz/{from.md → to.md}
RENAMED
|
@@ -27,13 +27,13 @@ another thread to acquire ownership of that object will fail (for
|
|
| 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.
|
| 33 |
-
|
| 34 |
-
|
| 35 |
typically occur when a reference-counted object contains a mutex that is
|
| 36 |
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
|
|
|
|
| 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. Conforming
|
| 33 |
+
implementations handle such scenarios correctly, as long as thread `A`
|
| 34 |
+
does not access the mutex after the unlock call returns. These cases
|
| 35 |
typically occur when a reference-counted object contains a mutex that is
|
| 36 |
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
|