From Jason Turner

[thread.mutex.requirements.mutex.general]

C++20 → C++23 4.6 KB 118 lines
Current Draft | LaTeX Source
Archived: C++20 | C++23
Markdown: C++20 | C++23
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmpgvl9x34t/{from.md → to.md} +115 -0
tmp/tmpgvl9x34t/{from.md → to.md} RENAMED
@@ -0,0 +1,115 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ ##### General <a id="thread.mutex.requirements.mutex.general">[[thread.mutex.requirements.mutex.general]]</a>
2
+
3
+ The *mutex types* are the standard library types `mutex`,
4
+ `recursive_mutex`, `timed_mutex`, `recursive_timed_mutex`,
5
+ `shared_mutex`, and `shared_timed_mutex`. They meet the requirements set
6
+ out in [[thread.mutex.requirements.mutex]]. In this description, `m`
7
+ denotes an object of a mutex type.
8
+
9
+ [*Note 1*: The mutex types meet the *Cpp17Lockable* requirements
10
+ [[thread.req.lockable.req]]. — *end note*]
11
+
12
+ The mutex types meet *Cpp17DefaultConstructible* and
13
+ *Cpp17Destructible*. If initialization of an object of a mutex type
14
+ fails, an exception of type `system_error` is thrown. The mutex types
15
+ are neither copyable nor movable.
16
+
17
+ The error conditions for error codes, if any, reported by member
18
+ functions of the mutex types are as follows:
19
+
20
+ - `resource_unavailable_try_again` — if any native handle type
21
+ manipulated is not available.
22
+ - `operation_not_permitted` — if the thread does not have the privilege
23
+ to perform the operation.
24
+ - `invalid_argument` — if any native handle type manipulated as part of
25
+ mutex construction is incorrect.
26
+
27
+ The implementation provides lock and unlock operations, as described
28
+ below. For purposes of determining the existence of a data race, these
29
+ behave as atomic operations [[intro.multithread]]. The lock and unlock
30
+ operations on a single mutex appears to occur in a single total order.
31
+
32
+ [*Note 2*: This can be viewed as the modification order
33
+ [[intro.multithread]] of the mutex. — *end note*]
34
+
35
+ [*Note 3*: Construction and destruction of an object of a mutex type
36
+ need not be thread-safe; other synchronization can be used to ensure
37
+ that mutex objects are initialized and visible to other
38
+ threads. — *end note*]
39
+
40
+ The expression `m.lock()` is well-formed and has the following
41
+ semantics:
42
+
43
+ *Preconditions:* If `m` is of type `mutex`, `timed_mutex`,
44
+ `shared_mutex`, or `shared_timed_mutex`, the calling thread does not own
45
+ the mutex.
46
+
47
+ *Effects:* Blocks the calling thread until ownership of the mutex can be
48
+ obtained for the calling thread.
49
+
50
+ *Synchronization:* Prior `unlock()` operations on the same object
51
+ *synchronize with*[[intro.multithread]] this operation.
52
+
53
+ *Ensures:* The calling thread owns the mutex.
54
+
55
+ *Return type:* `void`.
56
+
57
+ *Throws:* `system_error` when an exception is
58
+ required [[thread.req.exception]].
59
+
60
+ *Error conditions:*
61
+
62
+ - `operation_not_permitted` — if the thread does not have the privilege
63
+ to perform the operation.
64
+ - `resource_deadlock_would_occur` — if the implementation detects that a
65
+ deadlock would occur.
66
+
67
+ The expression `m.try_lock()` is well-formed and has the following
68
+ semantics:
69
+
70
+ *Preconditions:* If `m` is of type `mutex`, `timed_mutex`,
71
+ `shared_mutex`, or `shared_timed_mutex`, the calling thread does not own
72
+ the mutex.
73
+
74
+ *Effects:* Attempts to obtain ownership of the mutex for the calling
75
+ thread without blocking. If ownership is not obtained, there is no
76
+ effect and `try_lock()` immediately returns. An implementation may fail
77
+ to obtain the lock even if it is not held by any other thread.
78
+
79
+ [*Note 1*: This spurious failure is normally uncommon, but allows
80
+ interesting implementations based on a simple compare and
81
+ exchange [[atomics]]. — *end note*]
82
+
83
+ An implementation should ensure that `try_lock()` does not consistently
84
+ return `false` in the absence of contending mutex acquisitions.
85
+
86
+ *Synchronization:* If `try_lock()` returns `true`, prior `unlock()`
87
+ operations on the same object *synchronize with*[[intro.multithread]]
88
+ this operation.
89
+
90
+ [*Note 2*: Since `lock()` does not synchronize with a failed subsequent
91
+ `try_lock()`, the visibility rules are weak enough that little would be
92
+ known about the state after a failure, even in the absence of spurious
93
+ failures. — *end note*]
94
+
95
+ *Return type:* `bool`.
96
+
97
+ *Returns:* `true` if ownership was obtained, otherwise `false`.
98
+
99
+ *Throws:* Nothing.
100
+
101
+ The expression `m.unlock()` is well-formed and has the following
102
+ semantics:
103
+
104
+ *Preconditions:* The calling thread owns the mutex.
105
+
106
+ *Effects:* Releases the calling thread’s ownership of the mutex.
107
+
108
+ *Return type:* `void`.
109
+
110
+ *Synchronization:* This operation synchronizes
111
+ with [[intro.multithread]] subsequent lock operations that obtain
112
+ ownership on the same object.
113
+
114
+ *Throws:* Nothing.
115
+