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

N4488: Responses to PDTS comments on Transactional Memory, version 2

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".

Changes compared to N4410

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]:
... Beginning with section 1.4 1.10 below, 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.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 [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

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], 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.