-
Notifications
You must be signed in to change notification settings - Fork 6
Expand file tree
/
Copy pathn4265.html
More file actions
2120 lines (1581 loc) · 68.1 KB
/
n4265.html
File metadata and controls
2120 lines (1581 loc) · 68.1 KB
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
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
<title>N4265: Transactional Memory Support for C++: Wording (revision 3)</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>
N4265<br>
revision of N3999, N4179<br>
Jens Maurer<br>
2014-11-07
<h1>N4265: Transactional Memory Support for C++: Wording (revision 3)</h1>
<blockquote>
Jens Maurer, jens.maurer@gmx.net<br>
</blockquote>
with other members of the transactional memory study group (SG5),
including (in alphabetical order):
<blockquote>
Hans Boehm, hboehm@google.com<br>
Justin Gottschlich, justin.e.gottschlich@intel.com<br>
Victor Luchangco, victor.luchangco@oracle.com<br>
Paul McKenney, paulmck@linux.vnet.ibm.com<br>
Maged Michael, maged.michael@gmail.com<br>
Mark Moir, mark.moir@oracle.com<br>
Torvald Riegel, triegel@redhat.com<br>
Michael Scott, scott@cs.rochester.edu<br>
Tatiana Shpeisman, tatiana.shpeisman@intel.com<br>
Michael Spear, spear@cse.lehigh.edu<br>
Michael Wong, michaelw@ca.ibm.com (chair of SG5)<br>
</blockquote>
<h2>Introduction</h2>
<p>
This paper presents the current wording proposal (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>
<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>
<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
<ul>
<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>Open issues</h2>
<ul>
<li>Exception handling might call std::terminate, which
invokes a terminate handler. That terminate handler is a function
pointer not declared <code>transaction_safe</code>, so there is a gap in the
specification if std::terminate ends up being called inside an atomic
transaction. The intersection of desirable and implementable semantics
for this case is still under discussion.</li>
<li>Initialization of variables with static storage duration.</li>
<li>Atomic blocks that do not access shared memory locations should
not receive or cause an inter-thread-happens-before edge, i.e. atomic
blocks cannot be used as a replacement for fences. [Chandler Carruth
in Issaquah (February 2014): this allows to remove hardware-level
synchronization cost if the compiler can prove that an atomic block is
entirely local.]</li>
<li>At first sight, the math functions from <math.h> (e.g. "sin")
are transaction-safe. However, they may need to inspect hardware
state such as the current rounding mode that might make them unfit for
transactional execution.</li>
<li>investigate use of <code>std::function</code> inside
transactions</li>
<li>(postponed) Consider describing synchronized blocks entirely as-if
taking a global mutex.</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>
<h2>Section 1.10 [intro.multithread] Multi-threaded executions and
data races</h2>
Add a paragraph to section 1.10 [intro.multithread] after
paragraph 8:
<blockquote class="new">
The start and the end of each synchronized block or atomic block is a
full-expression (1.9 [intro.execution]). A synchronized block (6.x
[stmt.sync]) or atomic block (6.x [stmt.tx]) that is not dynamically
nested within another synchronized block or atomic block is called an
outer block. [ Note: Due to syntactic constraints,
blocks cannot overlap unless one is nested within the
other. ] There is a global total order of execution for all outer
blocks. If, in that total order, T1 is ordered before T2, then the
end of T1 synchronizes with the start of T2.
</blockquote>
<p>
<em>Drafting notes: Together with 1.9p14, the first sentence ensures
the appropriate (thread-local) sequencing. Inter-thread ordering is
ensured by establishing a synchronizes-with relationship in the last
sentence.</em>
</p>
Change in 1.10 [intro.multithread] paragraph 10:
<blockquote>
<ins>Synchronized and atomic blocks as well as certain</ins>
<del>Certain</del> library calls <em>synchronize with</em>
other <ins>synchronized blocks, atomic blocks,
and</ins> library calls performed by another thread.
</blockquote>
Change in 1.10 [intro.multithread] paragraph 21, and add a new
paragraph following it:
<blockquote>
The execution of a program contains a <em>data race</em> if it
contains two conflicting actions in different threads, at least one of
which is not atomic, and neither happens before the other. Any such
data race results in undefined behavior. [ Note: It can be shown that
programs that correctly use mutexes<ins>, synchronized and atomic
blocks,</ins> and <code>memory_order_seq_cst</code> operations to
prevent all data races and use no other synchronization operations
behave as if the operations executed by their constituent threads were
simply interleaved, with each value computation of an object being
taken from the last side effect on that object in that
interleaving. This is normally referred to as "sequential
consistency".
However, this applies only to data-race-free programs,
and data-race-free programs cannot observe most program
transformations that do not change single-threaded program
semantics. In fact, most single-threaded program transformations
continue to be allowed, since any program that behaves differently as
a result must perform an undefined operation. -- end note ]
</blockquote>
<blockquote class="new">
[ Note: Due to the constraints on transaction safety (8.4.4
[dcl.fct.def.tx]), the following holds for a data-race-free program:
If the start of an atomic block T is sequenced before an evaluation A,
A is sequenced before the end of T, and A inter-thread happens before
some evaluation B, then the end of T inter-thread happens before B.
If an evaluation C inter-thread happens before that evaluation A,
then C inter-thread happens before the start of T.
These properties in turn imply that in any simple interleaved
(sequentially consistent) execution, the operations of each atomic
block appear to be contiguous in the interleaving. -- end note ]
</blockquote>
<h2>Clause 2 [lex] Lexical conventions</h2>
<p>
In section 2.11 [lex.name] paragraph 2, add
<code>transaction_safe</code> and
<code>transaction_safe_noinherit</code> to the table.
</p>
<p>
In section 2.12 [lex.key], add the keywords
<code>synchronized</code>, <code>atomic_noexcept</code>,
<code>atomic_cancel</code>, and <code>atomic_commit</code> to
the table.
</p>
<h2>Clause 4 [conv] Standard conversions</h2>
Change in section 4.3 [conv.func] paragraph 1:
<blockquote>
An lvalue of function type T can be converted to a prvalue of type
"pointer to <del>T."</del> <ins>T".</ins> <ins>An lvalue of type "transaction-safe
function" can be converted to a prvalue of type "pointer to
function".</ins> The result is a pointer to the function. [ Footnote:
... ]
</blockquote>
<p>
<em>Drafting note: This ensures that overload resolution doesn't
perceive dropping the "transaction-safe" as two conversions instead
of just one. The same trick was applied for converting unscoped
enumerations with fixed underlying type to the promoted underlying
type (4.5p4).</em>
</p>
Add a new section 4.14 [conv.tx]:
<blockquote class="new">
<b>4.14 [conv.tx] Transaction-safety conversion</b><br>
<p>
A prvalue of type "pointer to <code>transaction_safe</code> function"
can be converted to a prvalue of type "pointer to function". The
result is a pointer to the function. A prvalue of type
"pointer to member of type <code>transaction_safe</code> function" can
be converted to a prvalue of type "pointer to member of type
function". The result points to the member function.
</p>
</blockquote>
<h2>Clause 5 [expr] Expressions</h2>
Change in 5 [expr] paragraph 13:
<blockquote>
[ Note: ... ] The <em>composite pointer type</em> of two operands p1
and p2 having types T1 and T2, respectively, where at least one is a
pointer or pointer to member type or <code>std::nullptr_t</code>, is:
<ul>
<li>...</li>
<li>if T1 or T2 is "pointer to cv1 void" and the other type is "pointer
to cv2 T", "pointer to cv12 void", where cv12 is the union of cv1 and
cv2 ;</li>
<li><ins>if T1 is "pointer to <code>transaction_safe</code> function"
and T2 is "pointer to function", where the function types are
otherwise the same, T2, and vice versa;</ins></li>
<li>...</li>
</ul>
</blockquote>
Change in 5.1.2 [expr.prim.lambda] paragraph 1:
<blockquote>
<pre><em>lambda-declarator:
( parameter-declaration-clause )</em> mutable<sub>opt</sub> <ins>transaction_safe<sub>opt</sub></ins>
<em>exception-specification<sub>opt</sub> attribute-specifier-seq<sub>opt</sub> trailing-return-type<sub>opt</sub> </em>
</pre>
</blockquote>
Change in 5.1.2 [expr.prim.lambda] paragraph 5:
<blockquote>
This function call operator or operator template is declared
<code>const</code> (9.3.1) if and only if the
<em>lambda-expression</em>'s <em>parameter-declaration-clause</em> is
not followed by <code>mutable</code>. It is neither virtual nor
declared volatile. <ins>It is declared <code>transaction_safe</code>
if and only if the <em>lambda-expression</em>'s
<em>parameter-declaration-clause</em> is followed by
<code>transaction_safe</code> or, in a non-generic
<em>lambda-expression</em>, it has a transaction-safe function
definition (8.4.4 [dcl.fct.def.tx]).</ins> Any
<em>exception-specification</em> specified on a
<em>lambda-expression</em> applies to the corresponding function call
operator or operator template. ...
</blockquote>
Change in 5.1.2 [expr.prim.lambda] paragraph 6:
<blockquote>
The closure type for a non-generic <em>lambda-expression</em> with no
<em>lambda-capture</em> has a public non-virtual non-explicit const
<ins><code>transaction_safe</code></ins> conversion function to
pointer to function with C++ language linkage (7.5 [dcl.link]) having
the same parameter and return types as the closure type's function
call operator. <ins>That pointer is a pointer to transaction-safe
function if the function call operator is transaction-safe.</ins>
</blockquote>
Add at the end of 5.2.2 [expr.call] paragraph 1:
<blockquote>
... [ Note: ... ] <ins>A call to a virtual function that is evaluated
within a synchronized (6.x [stmt.sync]) or atomic block (6.x
[stmt.tx]) results in undefined behavior if the virtual function is
declared <code> transaction_safe_noinherit</code> and the final
overrider is not declared <code>transaction_safe</code>.</ins>
</blockquote>
Add after 5.2.2 [expr.call] paragraph 9:
<blockquote>
<p>
Recursive calls are permitted, except to the function named main
(3.6.1)
</p>
<p class="new">
Calling a function that is not transaction-safe (8.4.4
[dcl.fct.def.tx]) through a pointer to or lvalue of type
"transaction-safe function" has undefined behavior.
</p>
</blockquote>
<p>
<em>Drafting note: This restriction might not be required if there is
no defined way of obtaining a pointer to transaction-safe function
from a pointer to (non-transaction-safe) function. One such way is
precluded by the next change.</em>
</p>
Change in 5.2.9 [expr.static.cast] paragraph 7:
<blockquote>
The inverse of any standard conversion sequence (Clause 4 [conv]) not
containing an lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer
(4.2 [conv.array]), function-to-pointer (4.3), null pointer (4.10),
null member pointer (4.11), <del>or</del> boolean (4.12)<ins>,
or transaction-safety (4.14 [conv.tx])</ins> conversion, can
be performed explicitly using <code>static_cast</code>. ...
</blockquote>
Change in 5.10 [expr.eq] paragraph 2:
<blockquote>
If at least one of the operands is a pointer, pointer conversions
(4.10 [conv.ptr])<ins>, transaction-safety conversions (4.14
[conv.tx]),</ins> and qualification conversions (4.4 [conv.qual]) are
performed on both operands to bring them to their composite pointer
type (clause 5 [expr]). Comparing pointers is defined as follows:
<ins>Before transaction-safety conversions, if one pointer is of type
"pointer to function", the other is of type "pointer
to <code>transaction_safe</code> function", and both point to the same
function, it is unspecified whether the pointers compare equal.
Otherwise,</ins> <del>Two</del> <ins>two</ins> pointers compare equal
if they are both null, both point to the same function, or both
represent the same address (3.9.2), otherwise they compare unequal.
</blockquote>
Change in 5.16 [expr.con] paragraph 6:
<blockquote>
<ul>
<li>One or both of the second and third operands have pointer type;
pointer conversions (4.10 [conv.ptr])<ins>, transaction-safety
conversions (4.14 [conv.tx]),</ins> and qualification conversions (4.4
[conv.qual]) are performed to bring them to their composite pointer type
(5 [expr]). ...</li>
<li>...</li>
</ul>
</blockquote>
<h2>Clause 6 [stmt.stmt] Statements</h2>
In 6 [stmt.stmt] paragraph 1, add two productions to
the grammar:
<blockquote>
<pre><em>
statement:
labeled-statement
attribute-specifier-seq<sub>opt</sub> expression-statement
attribute-specifier-seq<sub>opt</sub> compound-statement
attribute-specifier-seq<sub>opt</sub> selection-statement
attribute-specifier-seq<sub>opt</sub> iteration-statement
attribute-specifier-seq<sub>opt</sub> jump-statement
declaration-statement
attribute-specifier-seq<sub>opt</sub> try-block
<ins>synchronized-statement</ins>
<ins>atomic-statement</ins>
</em>
</pre>
</blockquote>
Add a new paragraph 3 at the end of 6.6 [stmt.jump]:
<blockquote class="new">
Transfer out of an atomic block other than via an exception executes
the end of the atomic block. [ Note: Colloquially, this is known as
committing the transaction. For exceptions, see 15.2
[except.ctor]. -- end note ] Transfer out of a synchronized
block (including via an exception) executes the end of the
synchronized block.
</blockquote>
Add a new section 6.x [stmt.sync]:
<blockquote class="new">
<b>6.x [stmt.sync] Synchronized statement</b><br>
<pre><em>synchronized-statement</em>:
synchronized <em>compound-statement</em>
</pre>
<p>
A synchronized statement is also called a <em>synchronized
block</em>.
</p>
<p>
The <em>start of the synchronized block</em> is immediately before the
opening <code>{</code> of the <em>compound-statement</em>. The
<em>end of the synchronized block</em> is immediately after the
closing <code>}</code> of the <em>compound-statement</em>.
</p>
<p>
A <code>goto</code> or <code>switch</code> statement shall not be used
to transfer control into a synchronized block.
</p>
<p>[ Example:</p>
<pre>int f()
{
static int i = 0;
synchronized {
printf("before %d\n", i);
++i;
printf("after %d\n", i);
return i;
}
}
</pre>
Each invocation of <code>f</code> (even when called from several
threads simultaneously) retrieves a unique value (ignoring overflow).
The output is guaranteed to comprise consistent
before/after pairs. -- end example ]
</blockquote>
Add a new section 6.x [stmt.tx]:
<blockquote class="new">
<b>6.x [stmt.tx] Atomic statement</b><br>
<pre><em>atomic-statement</em>:
atomic_noexcept <em>compound-statement</em>
atomic_cancel <em>compound-statement</em>
atomic_commit <em>compound-statement</em>
</pre>
<p>
An atomic statement is also called an <em>atomic block</em>. The
program is ill-formed if the <em>compound-statement</em> is a
transaction-unsafe statement (8.4.4 [dcl.fct.def.tx]).
</p>
<p>
The <em>start of the atomic block</em> is immediately
before the opening <code>{</code> of the <em>compound-statement</em>.
The <em>end of the atomic block</em> is immediately
after the closing <code>}</code> of the <em>compound-statement</em>. [
Note: Thus, variables with automatic storage duration declared in the
<em>compound-statement</em> are destroyed prior to reaching the end of
the atomic block; see 6.6 [stmt.jump]. -- end note ]
</p>
<p>
A <code>goto</code> or <code>switch</code> statement shall not be used
to transfer control into an atomic block.
</p>
<p>[ Example:</p>
<pre>int f()
{
static int i = 0;
atomic_noexcept {
++i;
return i;
}
}
</pre>
Each invocation of <code>f</code> (even when called from several
threads simultaneously) retrieves a unique value (ignoring overflow).
-- end example ]
</blockquote>
<h2>Section 7 [dcl.dcl] Declarations</h2>
Change in 7.4 [dcl.asm] paragraph 1:
<blockquote>
... The asm declaration is conditionally-supported; its meaning is
implementation-defined. [ Note: Typically it is used to pass
information through the implementation to an assembler. -- end note ]
<ins>It is implementation-defined which asm declarations are
transaction-safe (8.4.4 [dcl.fct.def.tx]), if any.</ins>
</blockquote>
Add a new section 7.6.6 [dcl.attr.sync]:
<blockquote class="new">
<b>7.6.6 [dcl.attr.sync] Attribute for optimization in synchronized blocks</b>
<p>
The <em>attribute-token</em> <code>optimize_for_synchronized</code>
specifies that a function definition should be optimized for
invocation from a <em>synchronized-statement</em> (6.x [stmt.sync]).
It shall appear at most once in each <em>attribute-list</em> and no
<em>attribute-argument-clause</em> shall be present. The attribute may
be applied to the <em>declarator-id</em> in a function declaration.
The first declaration of a function shall specify the
<code>optimize_for_synchronized</code> attribute if any declaration of
that function specifies the <code>optimize_for_synchronized</code>
attribute. If a function is declared with the
<code>optimize_for_synchronized</code> attribute in one translation
unit and the same function is declared without the
<code>optimize_for_synchronized</code> attribute in another
translation unit, the program is ill-formed; no diagnostic required.
</p><p>
[ Example:
</p><pre>// translation unit 1
[[optimize_for_synchronized]] int f(int);
void g(int x) {
synchronized {
int ret = f(x*x);
}
}
// translation unit 2
#include <iostream>
extern int verbose;
[[optimize_for_synchronized]] int f(int x)
{
if (x >= 0)
return x;
if (verbose > 1)
std::cerr << "failure: negative x" << std::endl;
return -1;
}
</pre>
If the attribute were not present for <code>f</code>, which is not
declared <code>transaction_safe</code>, a program might have to drop
out of speculative execution in <code>g</code>'s synchronized block
every time when calling <code>f</code>, although that is only actually
required for displaying the error message in the rare verbose error case.
-- end example ]
</blockquote>
<h2>Section 8 [dcl.decl] Declarators</h2>
Change in clause 8 paragraph 4:
<blockquote>
<pre><em>parameters-and-qualifiers</em>:
( <em>parameter-declaration-clause</em> ) <em>cv-qualifier-seq<sub>opt</sub>
ref-qualifier<sub>opt</sub></em> <ins><em>tx-qualifier</em><sub>opt</sub></ins> <em>exception-specification<sub>opt</sub> attribute-specifier-seq<sub>opt</sub></em>
<ins><em>tx-qualifier</em>:
transaction_safe
transaction_safe_noinherit</ins>
</pre>
</blockquote>
Change in 8.3.5 [dcl.fct] paragraphs 1 and 2:
<blockquote>
In a declaration T D where D has the form
<pre> D1 ( <em>parameter-declaration-clause</em> ) <em>cv-qualifier-seq<sub>opt</sub>
ref-qualifier<sub>opt</sub></em> <ins><em>tx-qualifier</em><sub>opt</sub></ins> <em>exception-specification<sub>opt</sub> attribute-specifier-seq<sub>opt</sub></em>
</pre>
and the type of the contained <em>declarator-id</em> in the
declaration T D1 is "derived-declarator-type-list T", the type of the
<em>declarator-id</em> in D is "derived-declarator-type-list
<ins><code>transaction_safe</code><sub>opt</sub></ins> function of
(parameter-declaration-clause)
<em>cv-qualifier-seq<sub>opt</sub> ref-qualifier<sub>opt</sub></em>
returning T"<ins>, where the optional <code>transaction_safe</code> is present if a <em>tx-qualifier</em> is present</ins>. The
optional <em>attribute-specifier-seq</em> appertains to the function type.
<p>
In a declaration T D where D has the form
</p><pre> D1 ( <em>parameter-declaration-clause</em> ) <em>cv-qualifier-seq<sub>opt</sub>
ref-qualifier<sub>opt</sub></em> <ins><em>tx-qualifier</em><sub>opt</sub></ins> <em>exception-specification<sub>opt</sub> attribute-specifier-seq<sub>opt</sub> trailing-return-type</em>
</pre>
and the type of the contained <em>declarator-id</em> in the
declaration T D1 is "derived-declarator-type-list T", T shall be the
single <em>type-specifier</em> auto. The type of the
<em>declarator-id</em> in D is "derived-declarator-type-list
<ins><code>transaction_safe</code><sub>opt</sub></ins> function of
(parameter-declaration-clause) <em>cv-qualifier-seq<sub>opt</sub>
ref-qualifier<sub>opt</sub></em> returning
<em>trailing-return-type</em>"<ins>, where the optional <code>transaction_safe</code> is present if a <em>tx-qualifier</em> is present</ins>.
The optional <em>attribute-specifier-seq</em>
appertains to the function type.
</blockquote>
Change in 8.3.5 [dcl.fct] paragraph 5:
<blockquote>
... After determining the type of each parameter, any parameter of
type "array of T" or "<ins><code>transaction_safe</code><sub>opt</sub></ins>
function returning T" is adjusted to be "pointer to T" or "pointer to
<ins><code>transaction_safe</code><sub>opt</sub></ins> function returning T,"
respectively. ...
</blockquote>
Change in 8.3.5 [dcl.fct] paragraph 6:
<blockquote>
... The return type, the parameter-type-list, the
<em>ref-qualifier</em>, <del>and</del> the <em>cv-qualifier-seq</em>,
<ins>and the <code>transaction_safe</code>
qualifier,</ins> but not the default arguments (8.3.6
[dcl.fct.default]) or the <em>exception specification</em> (15.4
[except.spec]), are part of the function type. ...
</blockquote>
Add at the end of section 8.3.5 [dcl.fct]:
<blockquote class="new">
<p>
The <code>transaction_safe_noinherit</code> qualifier
may only appear in a function declarator that declares a virtual
function in a class definition. A virtual function declared
with the <code>transaction_safe_noinherit</code>
qualifier is considered to be declared
<code>transaction_safe</code>. [ Note: A virtual function so declared
can be overridden by a function that is not transaction-safe (see 10.3
class virtual), but calling such an overrider from a synchronized or
atomic block causes undefined behavior (see 5.2.2 expr.call). -- end
note ]
All declarations of a function shall be declared
<code>transaction_safe</code> if any declaration of that function is
declared <code>transaction_safe</code>, except that the declaration of
an explicit specialization (14.7.3 [temp.expl.spec]) may differ from
the declaration that would be instantiated from the
template; no diagnostic is required if conflicting
declarations appear in different translation units.
</p>
</blockquote>
Change in section 8.4.1 [dcl.fct.def.general] paragraph 2:
<blockquote>
The <em>declarator</em> in a <em>function-definition</em> shall have
the form
<pre> D1 <del>( <em>parameter-declaration-clause</em> ) <em>cv-qualifier-seq<sub>opt</sub>
ref-qualifier<sub>opt</sub> exception-specification<sub>opt</sub> attribute-specifier-seq<sub>opt</sub></em></del>
<em><ins>parameters-and-qualifiers</ins> trailing-return-type<sub>opt</sub></em>
</pre>
</blockquote>
<p>
<em>[ Drafting note: This is intended to reduce the grammar
redundancies around function declarators. ]</em>
</p>
Add a section after 8.4.3 [dcl.fct.def.delete]:
<blockquote class="new">
<b>8.4.4 [dcl.fct.def.tx] Transaction-safe function
definitions</b><br>
<p>
An expression is <em>transaction-unsafe</em> if it contains any of the
following as a potentially-evaluated subexpression (3.2
[basic.def.odr]):
</p>
<ul>
<li>an lvalue-to-rvalue conversion (4.1 [conv.lval]) applied to a
volatile glvalue [ Note: referring to a volatile object through a
non-volatile glvalue has undefined behavior; see 7.1.6.1 [dcl.type.cv]
-- end note ],</li>
<li>an expression that modifies an object through a volatile glvalue,</li>
<li>the creation of a temporary object of volatile-qualified type
or with a subobject of volatile-qualified type,</li>
<li>a function call (5.2.2 expr.call) whose
<em>postfix-expression</em> is an <em>id-expression</em> that names a
non-virtual function that is not transaction-safe,</li>
<li>an implicit call of a non-virtual function that is not
transaction-safe, or</li>
<li>any other call of a function, where the function
type is not "<code>transaction_safe</code> function".</li>
</ul>
<p>
A statement is a <em>transaction-unsafe statement</em> if it
lexically directly contains one of the following (including
evaluations of default argument expressions in function calls
and evaluations of <em>brace-or-equal-initializer</em>s for
non-static data members in aggregate initialization (8.5.1
dcl.init.aggr), but ignoring the declaration of default
argument expressions, local classes, and the
<em>compound-statement</em> of a <em>lambda-expression</em>):
</p>
<ul>
<li>a full-expression that is transaction-unsafe,</li>
<li>an <em>asm-definition</em> (7.4 [dcl.asm]) that is not
transaction-safe,</li>
<li>a declaration of a variable of volatile-qualified type or
with a subobject of volatile-qualified type, or</li>
<li>a statement that is transaction-unsafe (recursively).</li>
</ul>
</blockquote>
<em>[ Drafting note: This wording is intended to recurse through the
"statement" grammar, but not inside expressions. In particular, the
compound-statement of a lambda determines the transaction-safety of
the lambda's operator() function, but, unless called, does not
influence the transaction-safety of the surrounding context. ]</em>
<blockquote class="new">
A function has a <em>transaction-safe definition</em> if none of the
following applies:
<ul>
<li>any parameter has volatile-qualified type or has a subobject of volatile-qualified type,</li>
<li>its <em>compound-statement</em> (including the one in the
<em>function-try-block</em>, if any) is a transaction-unsafe statement,</li>
<li>for a constructor or destructor, the corresponding class has
a volatile non-static data member, or</li>
<li>for a constructor, a full-expression in a
<em>mem-initializer</em> or an <em>assignment-expression</em> in a
<em>brace-or-equal-initializer</em> that is not ignored (12.6.2
[class.base.init]) is transaction-unsafe.</li>
</ul>
[ Example:
<pre> extern volatile int * p = 0;
struct S {
virtual ~S();
};
int f() transaction_safe {
int x = 0; // ok: not volatile
p = &x; // ok: the pointer is not volatile
int i = *p; // error: read through volatile glvalue
S s; // error: invocation of unsafe destructor
}
</pre>
-- end example ]
<p>
A function declared <code>transaction_safe</code> shall have a
transaction-safe definition.
</p>
<p>
A function is <em>transaction-safe</em> if it is declared
<code>transaction_safe</code> (see 8.3.5 [dcl.fct]), or if it is
a non-virtual function defined before its first
odr-use (3.2 [basic.def.odr]) and it has a transaction-safe function
definition. A specialization of a function template or of a member
function of a class template, where the function or function template
is not declared <code>transaction_safe</code>, but defined before the
first point of instantiation, is transaction-safe if and only if it
satisfies the conditions for a transaction-safe function definition. [
Note: Even if a function is implicitly transaction-safe, its function
type is not changed to "<code>transaction_safe</code> function". --
end note ]
</p>
<p>
While determining whether a function <code>f</code> is
transaction-safe, <code>f</code> is assumed to be
transaction-safe for directly and indirectly recursive
calls. [ Example:
</p><pre> int f(int x) { // is transaction-safe
if (x <= 0)
return 0;
return x + f(x-1);
}
</pre>
-- end example ]
<p></p>
</blockquote>
<em>Drafting note: Implicitly-defined special member functions and
lambda expressions should be automatically covered by the wording
above.</em>
<h2>Section 10.3 [class.virtual] Virtual functions</h2>
Add a new paragraph at the end of section 10.3 [class.virtual]: