<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>N4488: Responses to PDTS comments on Transactional Memory, version 2</title>

<style type="text/css">
  ins { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .new { text-decoration:none; font-weight:bold; background-color:#D0FFD0 }
  del { text-decoration:line-through; background-color:#FFA0A0 }
  strong { font-weight: inherit; color: #2020ff }
  .old { background-color:#ffff40 }
  .old ins { background-color:#a0ff30 }
</style>

</head>

<body>

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

<h1>N4488: Responses to PDTS comments on Transactional Memory, version 2</h1>

<blockquote>
Jens Maurer, jens.maurer@gmx.net<br/>
</blockquote>

with other members of the transactional memory study group (SG5),
including (in alphabetical order):

<blockquote>
Hans Boehm, hboehm@google.com<br/>
Victor Luchangco, victor.luchangco@oracle.com<br/>
Paul McKenney, paulmck@linux.vnet.ibm.com<br/>
Maged Michael, maged.michael@gmail.com<br/>
Mark Moir, mark.moir@oracle.com<br/>
Torvald Riegel, triegel@redhat.com<br/>
Michael Scott, scott@cs.rochester.edu<br/>
Tatiana Shpeisman, tatiana.shpeisman@intel.com<br/>
Michael Spear, spear@cse.lehigh.edu<br/>
Michael Wong, michaelw@ca.ibm.com (chair of SG5)<br/>
</blockquote>


<h2>Introduction</h2>

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

<h2>Changes compared to N4410</h2>

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


<h2>JP 1: Performance degradation</h2>

REJECT
<p>

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.
<p>
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 &lt;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.


<h2>US 1: Relax synchronization to allow optimizations on local transactions</h2>

ACCEPT
<p>

In section 1.10 intro.multithread, change the added paragraph 9 as
follows:

<blockquote>
There is a global total order of execution for all outer blocks.  If,
in that total order, T1 is ordered before T2,
<ul>
<li><ins>no evaluation in T2 happens before any evaluation in T1 and</ins>

<li><ins>if T1 and T2 perform conflicting expression
evaluations,</ins> then the end of T1 synchronizes with the start of
T2.</li>

</ul>

</blockquote>


<h2>CA 1: Feature Test Macro</h2>

ACCEPT
</p>

Change in section 1.3 [general.references]:

<blockquote>

...  Beginning with section <del>1.4</del> <ins>1.10</ins> 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 <del>1.3</del> <ins>1.5</ins> of this
Technical Specification are introductory material and are unrelated to
the similarly-numbered sections of the C++ Standard.

</blockquote>

Change in section 1.4 [intro.compliance]:

<blockquote>
Conformance requirements for this specification are the same as those
defined in <ins>section</ins> 1.4 [intro.compliance] <ins>of the C++
Standard</ins>. [ Note: Conformance is defined in terms of the
behavior of programs. -- end note ]

</blockquote>

Add a new section 1.5 [intro.features]:

<blockquote class="new">
<p>
<b>1.5 Feature testing [intro.features]</b>
</p>

<p>
An implementation that provides support for this Technical
Specification shall define the feature test macro in Table
1.


<p align=center>
Table 1 -- Feature Test Macro
</p>
<table align=center border="1" cellspacing="0" cellpadding="4">
<tr>
<td align=center>Name</td>
<td align=center>Value</td>
<td align=center>Header</td>
</tr>
<tr>
<td><tt>__cpp_transactional_memory</tt> </td>
<td>201505</td>
<td><em>predeclared</em></td>
</tr>
</table>

</blockquote>


<h2>CA 3: Make helper functions transaction-safe</h2>

ACCEPT
<p>

Add the following to the appropriate sections:

<blockquote class="new">
Add in 20.2 [utility] after the synopsis:

<blockquote>
<ins>A function in this section is transaction-safe if all required
operations are transaction-safe.</ins>
</blockquote>

In 20.2.4 [forward], add "<code>transaction_safe</code>" to the
declaration of all functions.

</blockquote>


<h2>CA 2: Virtual function calls in synchronized blocks</h2>

ACCEPT
<p>

Change the added text in 5.2.2 [expr.call] paragraph 1:

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

</blockquote>


<h2>FI 1: Rename <code>transaction_safe_noinherit</code> to
<code>transaction_safe_dynamic</code></h2>

ACCEPT
<p>

Change all mentions of <code>transaction_safe_noinherit</code> to
<code>transaction_safe_dynamic</code>, 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].


<h2>JP 2: Initialization of function-local static variables</h2>

REJECT
<p>

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.


<h2>CA 4: Redundant case for transaction-unsafe expressions</h2>

REJECT
<p>

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.

</body>
</html>
