tmp/tmphb0hbmx0/{from.md → to.md}
RENAMED
|
@@ -0,0 +1,66 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
##### General <a id="thread.timedmutex.requirements.general">[[thread.timedmutex.requirements.general]]</a>
|
| 2 |
+
|
| 3 |
+
The *timed mutex types* are the standard library types `timed_mutex`,
|
| 4 |
+
`recursive_timed_mutex`, and `shared_timed_mutex`. They meet the
|
| 5 |
+
requirements set out below. In this description, `m` denotes an object
|
| 6 |
+
of a mutex type, `rel_time` denotes an object of an instantiation of
|
| 7 |
+
`duration` [[time.duration]], and `abs_time` denotes an object of an
|
| 8 |
+
instantiation of `time_point` [[time.point]].
|
| 9 |
+
|
| 10 |
+
[*Note 1*: The timed mutex types meet the *Cpp17TimedLockable*
|
| 11 |
+
requirements [[thread.req.lockable.timed]]. — *end note*]
|
| 12 |
+
|
| 13 |
+
The expression `m.try_lock_for(rel_time)` is well-formed and has the
|
| 14 |
+
following semantics:
|
| 15 |
+
|
| 16 |
+
*Preconditions:* If `m` is of type `timed_mutex` or
|
| 17 |
+
`shared_timed_mutex`, the calling thread does not own the mutex.
|
| 18 |
+
|
| 19 |
+
*Effects:* The function attempts to obtain ownership of the mutex within
|
| 20 |
+
the relative timeout [[thread.req.timing]] specified by `rel_time`. If
|
| 21 |
+
the time specified by `rel_time` is less than or equal to
|
| 22 |
+
`rel_time.zero()`, the function attempts to obtain ownership without
|
| 23 |
+
blocking (as if by calling `try_lock()`). The function returns within
|
| 24 |
+
the timeout specified by `rel_time` only if it has obtained ownership of
|
| 25 |
+
the mutex object.
|
| 26 |
+
|
| 27 |
+
[*Note 1*: As with `try_lock()`, there is no guarantee that ownership
|
| 28 |
+
will be obtained if the lock is available, but implementations are
|
| 29 |
+
expected to make a strong effort to do so. — *end note*]
|
| 30 |
+
|
| 31 |
+
*Synchronization:* If `try_lock_for()` returns `true`, prior `unlock()`
|
| 32 |
+
operations on the same object *synchronize with*[[intro.multithread]]
|
| 33 |
+
this operation.
|
| 34 |
+
|
| 35 |
+
*Return type:* `bool`.
|
| 36 |
+
|
| 37 |
+
*Returns:* `true` if ownership was obtained, otherwise `false`.
|
| 38 |
+
|
| 39 |
+
*Throws:* Timeout-related exceptions [[thread.req.timing]].
|
| 40 |
+
|
| 41 |
+
The expression `m.try_lock_until(abs_time)` is well-formed and has the
|
| 42 |
+
following semantics:
|
| 43 |
+
|
| 44 |
+
*Preconditions:* If `m` is of type `timed_mutex` or
|
| 45 |
+
`shared_timed_mutex`, the calling thread does not own the mutex.
|
| 46 |
+
|
| 47 |
+
*Effects:* The function attempts to obtain ownership of the mutex. If
|
| 48 |
+
`abs_time` has already passed, the function attempts to obtain ownership
|
| 49 |
+
without blocking (as if by calling `try_lock()`). The function returns
|
| 50 |
+
before the absolute timeout [[thread.req.timing]] specified by
|
| 51 |
+
`abs_time` only if it has obtained ownership of the mutex object.
|
| 52 |
+
|
| 53 |
+
[*Note 2*: As with `try_lock()`, there is no guarantee that ownership
|
| 54 |
+
will be obtained if the lock is available, but implementations are
|
| 55 |
+
expected to make a strong effort to do so. — *end note*]
|
| 56 |
+
|
| 57 |
+
*Synchronization:* If `try_lock_until()` returns `true`, prior
|
| 58 |
+
`unlock()` operations on the same object *synchronize
|
| 59 |
+
with*[[intro.multithread]] this operation.
|
| 60 |
+
|
| 61 |
+
*Return type:* `bool`.
|
| 62 |
+
|
| 63 |
+
*Returns:* `true` if ownership was obtained, otherwise `false`.
|
| 64 |
+
|
| 65 |
+
*Throws:* Timeout-related exceptions [[thread.req.timing]].
|
| 66 |
+
|