From Jason Turner

[thread.sharedtimedmutex.requirements.general]

Diff to HTML by rtfpessoa

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