ISO/IEC JTC 1/SC 22/WG 21 N4488
revises N4410
Jens Maurer
2015-05-07

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

Jens Maurer, jens.maurer@gmx.net
with other members of the transactional memory study group (SG5), including (in alphabetical order):
Hans Boehm, hboehm@google.com
Victor Luchangco, victor.luchangco@oracle.com
Paul McKenney, paulmck@linux.vnet.ibm.com
Maged Michael, maged.michael@gmail.com
Mark Moir, mark.moir@oracle.com
Torvald Riegel, triegel@redhat.com
Michael Scott, scott@cs.rochester.edu
Tatiana Shpeisman, tatiana.shpeisman@intel.com
Michael Spear, spear@cse.lehigh.edu
Michael Wong, michaelw@ca.ibm.com (chair of SG5)

Introduction

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

REJECT

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

ACCEPT

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

ACCEPT

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

ACCEPT

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

ACCEPT

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]) 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

ACCEPT

Change all mentions of transaction_safe_noinherit to 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], 18.6.2.1 [bad.alloc], 18.6.2.2 [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

REJECT

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

REJECT

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.