ISO/IEC JTC 1/SC 22/WG 21 N4410
Jens Maurer

N4410: Responses to PDTS comments on Transactional Memory

Jens Maurer,
with other members of the transactional memory study group (SG5), including (in alphabetical order):
Hans Boehm,
Victor Luchangco,
Paul McKenney,
Maged Michael,
Mark Moir,
Torvald Riegel,
Michael Scott,
Tatiana Shpeisman,
Michael Spear,
Michael Wong, (chair of SG5)


This paper presents the proposed responses to N4396 "National Body Comments, ISO/IEC PDTS 19841, C++ Extensions for Transactional Memory".

JP 1: Performance degradation


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.

US 1: Relax synchronization to allow optimizations on local transactions


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,

CA 1: Feature Test Macro


Change in section 1.3 [general.references]:
... Sections 1.1 through 1.3 1.5 of this Technical Specification are introductory material and are unrelated to the similarly-numbered sections of the C++ Standard.
Change in section 1.4 [intro.compliance]:
Conformance requirements for this specification are the same as those defined in section 1.4 [intro.compliance] of the C++ Standard. [ Note: Conformance is defined in terms of the behavior of programs. -- end note ]
Add a new section 1.5 [general.features]:

1.5 Feature-testing recommendations (Informative) [general.features]

For the sake of improved portability between partial implementations of various C++ standards and Technical Specifications, WG21 (the ISO Technical Committee for the C++ Programming Language) recommends that implementations follow the guidelines in this section concerning feature-test macros. [ Note: WG21's SD-6 makes similar recommendations for the C++ Standard. -- end note ]

An implementation that provides support for transactional memory as specified in this Technical Specification should define the macro __cpp__transactional_memory with the value 201505L, in the same circumstances under which the feature is available (for example, taking into account relevant command-line options), to indicate the presence of support for that feature. No header files should be required to test the macro.

CA 3: Make helper functions transaction-safe


Add the following to the appropriate sections:

Add in 20.2 [utility] after the synopsis:
A function in this section is transaction-safe if all required operations are transaction-safe.
In 20.2.4 [forward] and 20.2.5 [declval], add "transaction_safe" to the declaration of all functions.

CA 2: Virtual function calls in synchronized blocks


Change the added text in 5.2.2 [] paragraph 1:

A call to a virtual function that is evaluated within a synchronized (6.9 [stmt.sync]) or an atomic block (6.10 [stmt.tx]) results in undefined behavior if the virtual function is declared transaction_safe_noinherit transaction_safe_dynamic and the final overrider is not declared transaction_safe.

FI 1: Rename transaction_safe_noinherit to transaction_safe_dynamic


Change all mentions of transaction_safe_noinherit to transaction_safe_dynamic, including sections 2.11 [], 5.2.2 [] (see also CA 2, above), clause 8 [dcl.decl], 8.3.5 [dcl.fct], 10.3 [class.virtual], [bad.alloc], [new.badlength], 18.7.2 [bad.cast], 18.7.3 [bad.typeid], 18.8.1 [exception], 18.8.2 [bad.exception], and 19.2 [std.exceptions].

JP 2: Initialization of function-local static variables


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.

CA 4: Redundant case for transaction-unsafe expressions


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.