Jens Maurer, firstname.lastname@example.org other members of the transactional memory study group (SG5), including (in alphabetical order):
Hans Boehm, email@example.com
Victor Luchangco, firstname.lastname@example.org
Paul McKenney, email@example.com
Maged Michael, firstname.lastname@example.org
Mark Moir, email@example.com
Torvald Riegel, firstname.lastname@example.org
Michael Scott, email@example.com
Tatiana Shpeisman, firstname.lastname@example.org
Michael Spear, email@example.com
Michael Wong, firstname.lastname@example.org (chair of SG5)
This paper presents the proposed responses to N4396 "National Body Comments, ISO/IEC PDTS 19841, C++ Extensions for Transactional Memory".
The specification of transaction safety ensures that it is possible to compile code so that whether a given function call is executed in transaction context or outside of transaction context can be determined at compile time. Therefore, existing code that is executed outside of transactions and that does not use any of the transactional memory constructs will execute as before. The performance of code that actually uses transactions will depend on the available hardware support, similar to the fact that the performance of mutexes vs. accesses to atomic variables depends on a number of hardware and other factors.
A conservative approach was chosen for mandating the transaction-safety of standard library functions. Functions that conceivably access global state are not touched. In particular, the functions in the header <math.h> were intentionally not made transaction-safe in this Technical Specification, because the interaction of transactional memory with accesses to a potentially global rounding mode setting was deemed to require further study. As an exception, based on early user feedback, memory allocation is mandated to be transaction-safe, although it might access the global free store. Implementation experience shows that this does not negatively impact the performance of non-transactional executions.
In section 1.10 intro.multithread, change the added paragraph 9 as follows:
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.
... Beginning with sectionChange in section 1.4 [intro.compliance]:
1.4below, all clause and section numbers, titles, and symbolic references in [brackets] refer to the corresponding elements of the C++ Standard. Sections 1.1 through 1.3of this Technical Specification are introductory material and are unrelated to the similarly-numbered sections of the C++ Standard.
Conformance requirements for this specification are the same as those defined in 1.4 [intro.compliance] . [ Note: Conformance is defined in terms of the behavior of programs. -- end note ]Add a new section 1.5 [intro.features]:
1.5 Feature testing [intro.features]
An implementation that provides support for this Technical Specification shall define the feature test macro in Table 1.
Table 1 -- Feature Test Macro
Name Value Header __cpp_transactional_memory 201505 predeclared
Add the following to the appropriate sections:
Add in 20.2 [utility] after the synopsis:In 20.2.4 [forward], add "
transaction_safe" to the declaration of all functions.
Change the added text in 5.2.2 [expr.call] paragraph 1:
A call to a virtual function that is evaluated within
a synchronized (6.9 [stmt.sync]) oratomic block (6.10 [stmt.tx]) results in undefined behavior if the virtual function is declared and the final overrider is not declared
Change all mentions of
transaction_safe_dynamic, including sections 2.11
[lex.name], 5.2.2 [expr.call] (see also CA 2, above), clause 8
[dcl.decl], 8.3.5 [dcl.fct], 10.3 [class.virtual], 184.108.40.206
[bad.alloc], 220.127.116.11 [new.badlength], 18.7.2 [bad.cast], 18.7.3
[bad.typeid], 18.8.1 [exception], 18.8.2 [bad.exception], and 19.2
We agree that initialization of function-local statics should be atomic with respect to both transactional and non-transactional uses. We do not believe that the specification as drafted, taking into consideration the requirements on transaction safety, necessitates any additional overhead on the non-transactional code path once the initialization is complete.
The specification is carefully crafted to ensure that calls through function pointers or member function pointers fall into the sixth bullet. Omitting "implicit" in the fifth bullet would (arguably) defeat that purpose.