tmp/tmpyp6xpjfn/{from.md → to.md}
RENAMED
|
@@ -12,11 +12,11 @@ namespace std {
|
|
| 12 |
|
| 13 |
void lock();
|
| 14 |
bool try_lock();
|
| 15 |
void unlock();
|
| 16 |
|
| 17 |
-
|
| 18 |
native_handle_type native_handle(); // See~[thread.req.native]
|
| 19 |
};
|
| 20 |
}
|
| 21 |
```
|
| 22 |
|
|
@@ -24,26 +24,27 @@ 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 |
-
After a thread `A` has called `unlock()`, releasing a mutex,
|
| 30 |
-
possible for another thread `B` to lock the same mutex, observe
|
| 31 |
-
is no longer in use, unlock it, and destroy it, before thread
|
| 32 |
-
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
|
| 35 |
typically occur when a reference-counted object contains a mutex that is
|
| 36 |
-
used to protect the reference count.
|
| 37 |
|
| 38 |
-
The class `mutex` shall satisfy all the
|
| 39 |
[[thread.mutex.requirements]]). It shall be a standard-layout class
|
| 40 |
(Clause [[class]]).
|
| 41 |
|
| 42 |
-
A program may deadlock if the thread that owns a `mutex`
|
| 43 |
-
`lock()` on that object. If the implementation can detect
|
| 44 |
-
a `resource_deadlock_would_occur` error condition may be
|
|
|
|
| 45 |
|
| 46 |
The behavior of a program is undefined if it destroys a `mutex` object
|
| 47 |
owned by any thread or a thread terminates while owning a `mutex`
|
| 48 |
object.
|
| 49 |
|
|
|
|
| 12 |
|
| 13 |
void lock();
|
| 14 |
bool try_lock();
|
| 15 |
void unlock();
|
| 16 |
|
| 17 |
+
using native_handle_type = implementation-defined; // See~[thread.req.native]
|
| 18 |
native_handle_type native_handle(); // See~[thread.req.native]
|
| 19 |
};
|
| 20 |
}
|
| 21 |
```
|
| 22 |
|
|
|
|
| 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 3*: 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
|
| 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` shall satisfy all of the mutex requirements (
|
| 39 |
[[thread.mutex.requirements]]). It shall be a standard-layout class
|
| 40 |
(Clause [[class]]).
|
| 41 |
|
| 42 |
+
[*Note 4*: A program may 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 may be
|
| 45 |
+
observed. — *end note*]
|
| 46 |
|
| 47 |
The behavior of a program is undefined if it destroys a `mutex` object
|
| 48 |
owned by any thread or a thread terminates while owning a `mutex`
|
| 49 |
object.
|
| 50 |
|