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

Jens Maurer, jens.maurer@gmx.net

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

• fix a typo in the spelling of the feature test macro (two underscores in the middle)
• remove "L" suffix in value of feature test macro
• declval does not need to be transaction-safe, since it is never odr-used
• rework section CA 1

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,

• no evaluation in T2 happens before any evaluation in T1 and
• if T1 and T2 perform conflicting expression evaluations, then the end of T1 synchronizes with the start of T2.

CA 1: Feature Test Macro

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

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 ]

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 [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

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

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.