-
Notifications
You must be signed in to change notification settings - Fork 8
/
n4515.html
298 lines (217 loc) · 9.12 KB
/
n4515.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
<title>N4515: Editor's Report: Technical Specification for C++ Extensions for Transactional Memory</title>
<style type="text/css">
ins { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
.new { text-decoration:none; font-weight:bold; background-color:#D0FFD0 }
del { text-decoration:line-through; background-color:#FFA0A0 }
strong { font-weight: inherit; color: #2020ff }
.old { background-color:#ffff40 }
.old ins { background-color:#a0ff30 }
</style>
</head>
<body>
Document number: N4515<br>
Authors: Michael Wong<br>
Date: 2015-05-22 <br>
Reply-to: [email protected]<br>
Revision: of N4338<br>
<h1>Editor's Report: Technical Specification for C++ Extensions for Transactional Memory, post-Lenexa</h1>
<h2>Acknowledgment</h2>
We wish to thank comments from the Review Committee of Jens Maurer, Mike Miller, and Marshall Clow/Alisdair Meredith as well as the following:
<blockquote>
Hans Boehm<br>
Justin Gottschlich<br>
Victor Luchangco<br>
Jens Maurer<br>
Paul McKenney<br>
Maged Michael<br>
Mark Moir<br>
Torvald Riegel<br>
Michael Scott<br>
Tatiana Shpeisman<br>
Michael Spear<br>
Michael Wong<br>
</blockquote>
<h2>History</h2>
<h3>Lenexa (2015-05-08)</h3>
<p> passed EWG, CWG, LWG review. LEWG did not need to review the PDTS comment N4410 </p>
<p>
Move to approve N4513 as the Transactional Memory TS working paper
and direct the Convener to transmit N4514 for publication as the Transactional Memory TS.
Approvde unaimously in Lenexa
</p>
<p>
N4513 is the latest TM TS Working Draft. It contains changes to the TM TS as directed
by the committee at the Lenexa meeting based on the PDTS ballot comments.
</p>
<p>
N4514 is document N4513 reformatted as a PDTS ballot document.
</p>
<p>
N4515 is this document - TM TS Editor's report, post Lenexa.
</p>
<p>
<h2>Changes</h2>
<ul>
<li>Addresed NB PDTS comments in N4396 by N4410.</li>
</ul>
<h3>Post-Urbana (2014-11-21)</h3>
<p>N4396 is the PDTS 19841 NB comments </p>
<p>N4410 is SG5's responses to the PDTS comments in N4396>
</p>
<p>
N4301 is the latest TM TS Working Draft. It contains changes to the TM TS as directed
by the committee at the Urbana meeting combining N4272 and N4265.
</p>
<p>
N4302 is document N4301 reformatted as a PDTS ballot document.
</p>
<p>
N4338 is this document - TM TS Editor's report, post Urbana.
</p>
<h3>Urbana (2014-11-07)</h3>
<h4> Motion 3 (approved unanimously)</h4>
<p>
Move to create a working paper for the Technical Specification on C++ Extensions for
Transactional Memory with N4272, "Technical Specification on C++ Extensions for
Transactional Memory, Working Draft Header" and N4265,
"Transactional Memory Support for C++: Wording (revision 3)" as its initial content.
</p>
<p>
N4272 has the Working Draft front matter.
</p>
<p>
N4265 presents the wording proposal including changes from Urbana (both core and
library) for integrating transactional memory support into C++. For
motivation and introductory overview, see the predecessor paper N3999
"Standard Wording for Transactional Memory Support for C++".
</p>
<h3>Pre-Urbana (2014-10-10)</h3>
<p>
The companion paper N4180 motivates and explains the additional
features that have been integrated since the Rapperswil meeting. Those
were approved by EWG in Urbana.
</p>
<p>
N4179 presents the pre-Urbana integrated TM wording for core and library.
</p>
<h3>Pre-Rapperswil (2014-05-23)</h3>
<p>
N3999 presents a concise set of introduction, motivation, syntax, semantics and initial wording.
</p>
<p>
N4000 documents our effort to transactionalize a C++ Standard Template Library (STL)
container to demonstrate the feasibility of the transactional language constructs.
</p>
<h2>Changes</h2>
<ul>
<li>Addressed comments from 2014-06-02 review teleconference,
clarifying the wording.</li>
<li>Address CWG review comments from Rapperswil:
<ul>
<li>allow "synchronizes with" for non-library constructs</li>
<li>volatile subobjects are tx-unsafe</li>
<li>remove cross-translation unit safe-by-default</li>
<li>simplified lambda transaction-safety</li>
<li>redeclarations can omit <code>transaction_safe</code></li>
<li>comparing pointers is unspecified unless tx-safety is the same</li>
</ul>
</li>
<li>Address LWG review comments from Rapperswil:
<ul>
<li>added more cross-references in the library section</li>
<li>prohibit additional tx-safe annotations by library
implementations using the same words as for constexpr</li>
<li>for exception types that support tx cancellation, add notes about required implementation support</li>
<li>remove rand/srand, because some implementation use global
state where accesses are synchronized using a mutex</li>
</ul>
</li>
<li>add implicit conversion from "pointer to transaction_safe
member function" to "pointer to member function" (see
4.14)</li>
<li>clarify definition of transaction-safe (defined term)</li>
<li>added [[optimize_for_synchronized]] attribute (see section 7.6.6
[dcl.attr.sync])</li>
<li>added <code>transaction_safe noinherit</code> for virtual
functions (non-viral)</li>
<li>added transaction-safety for all containers and iterator-related
functions</li>
<li>added <code>tx_exception</code></li>
<li>Addressed comments from 2014-09-15 CWG review teleconference
</li>
<li>matching a <em>handler</em> performs transaction-safety conversions</li>
<li>allow, but do not require <code>transaction_safe</code> on lambdas
</li><li>a <code>transaction_safe noinherit</code> function overriding a <code>transaction_safe</code> function is ill-formed</li>
<li>template argument deduction performs transaction-safety conversions</li>
<li>allow forming a composite pointer type using a transaction-safety conversion</li>
</ul>
</li>
<li>rename <code>maybe transaction_safe</code> to <code>transaction_safe noinherit</code>
</li><li>Addressed comments from 2014-11-04 LWG review<
<ul>
<li>for the containers, make one blanket statement covering
all required functions and operations instead of detailed per-function
lists</li>
<li>reflect that not only user-provided functions, but also
built-in operations can make an instantiation of standard library
function template unsafe (e.g. std::copy invoked with "volatile int *"
parameters)</li>
<li>consider additional overloads in <cxxx> headers
(compared to the corresponding xxx.h header) for
tx-safety</li>
<li>C library functions should not be "declared" transaction-safe to
leave more room for implementers to have special compiler magic, not
requiring actual modifications of C headers</li>
<li>restrict <code>tx_exception</code> to trivially copyable
types</li>
<li>iterators of containers and rebound allocators are required to be
transaction-safe</li>
<li>also cover numerics algorithms (section 26.7)</li>
</ul></li>
<li>Renamed "transaction_safe noinherit" to
"transaction_safe_noinherit" per 2014-11-05 EWG review</li>
<li>Addressed comments from 2014-11-05 LWG review
</li><li>Addressed comments from 2014-11-05 CWG review
<ul>
<li>do not inherit transaction_safe for redeclarations; allow that explicit specializations differ</li>
</ul></li>
</ul>
<h2>Resolved issues</h2>
<ul>
<li>Under which circumstances is a lambda function (implicitly)
declared transaction-safe? [It is declared tx-safe if its definition
is (directly) safe and all invoked functions are tx-safe.] Do we want
to allow an explicit transaction_safe/unsafe annotation? [Yes to the
former.]</li>
<li>Is the term "transaction-statement" still ok, or should that be
renamed to "atomic-statement", in line with the (new) spelling of the
keywords? <em>Telco 2014-03-31: use "atomic block" and
"transaction-safe".</em></li>
<li>Allow conversion of "pointer to transaction-safe member function"
to "pointer to member function"</li>
<li>add "transaction_safe noinherit" for virtual functions</li>
<li><code>std::exception</code> is the base of the exception
hierarchy. Should we declare its virtual what() function
<code>transaction_safe</code>? [no; instead review definition of
derived classes such as length_error] This has serious ripple effects
to user code, in particular if that user code is totally unaware of
transactions. <em>Telco 2014-08-11 and 2014-09-08: introduce "maybe
transaction_safe" for virtual functions, which is not viral, but
accepts undefined behavior.</em></li>
<li>For "composite pointer type" in 5 [expr], address that T might be
"pointer to function" (not transaction-safe) vs. "pointer to
transaction-safe function". This can be unified to "pointer to
function" (not transaction-safe).</li>
<li>Introduce a
<pre>template<class T>
class tx_exception : exception { ... };
</pre>
with a transaction-safe "what()" function and where "T" can be
memcpy'd.</li>
<li>add "template specialization can be tx-safe even
when corresponding member of the template is not"</li>
</ul>
</body></html>