N4265: Transactional Memory Support for C++: Wording (revision 3)

Jens Maurer, jens.maurer@gmx.net

Hans Boehm, hboehm@google.com
Justin Gottschlich, justin.e.gottschlich@intel.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 current wording proposal (both core and library) for integrating transactional memory support into C++. For motivation and introductory overview, see the predecessor paper N3999 "Standard Wording for Transactional Memory Support for C++".

The companion paper N4180 motivates and explains the additional features that have been integrated since the Rapperswil meeting. Those were approved by EWG in Urbana.

Changes

• Addressed comments from 2014-06-02 review teleconference, clarifying the wording.
• Address CWG review comments from Rapperswil:
  • allow "synchronizes with" for non-library constructs
  • volatile subobjects are tx-unsafe
  • remove cross-translation unit safe-by-default
  • simplified lambda transaction-safety
  • redeclarations can omit transaction_safe
  • comparing pointers is unspecified unless tx-safety is the same
• Address LWG review comments from Rapperswil:
  • added more cross-references in the library section
  • prohibit additional tx-safe annotations by library implementations using the same words as for constexpr
  • for exception types that support tx cancellation, add notes about required implementation support
  • remove rand/srand, because some implementation use global state where accesses are synchronized using a mutex
• add implicit conversion from "pointer to transaction_safe member function" to "pointer to member function" (see 4.14)
• clarify definition of transaction-safe (defined term)
• added [[optimize_for_synchronized]] attribute (see section 7.6.6 [dcl.attr.sync])
• added transaction_safe noinherit for virtual functions (non-viral)
• added transaction-safety for all containers and iterator-related functions
• added tx_exception
• Addressed comments from 2014-09-15 CWG review teleconference
  • matching a handler performs transaction-safety conversions
  • allow, but do not require transaction_safe on lambdas
  • a transaction_safe noinherit function overriding a transaction_safe function is ill-formed
  • template argument deduction performs transaction-safety conversions
  • allow forming a composite pointer type using a transaction-safety conversion
• rename maybe transaction_safe to transaction_safe noinherit
• Addressed comments from 2014-11-04 LWG review<
  • for the containers, make one blanket statement covering all required functions and operations instead of detailed per-function lists
  • reflect that not only user-provided functions, but also built-in operations can make an instantiation of standard library function template unsafe (e.g. std::copy invoked with "volatile int *" parameters)
  • consider additional overloads in <cxxx> headers (compared to the corresponding xxx.h header) for tx-safety
  • C library functions should not be "declared" transaction-safe to leave more room for implementers to have special compiler magic, not requiring actual modifications of C headers
  • restrict tx_exception to trivially copyable types
  • iterators of containers and rebound allocators are required to be transaction-safe
  • also cover numerics algorithms (section 26.7)
• Renamed "transaction_safe noinherit" to "transaction_safe_noinherit" per 2014-11-05 EWG review
• Addressed comments from 2014-11-05 LWG review
• Addressed comments from 2014-11-05 CWG review
  • do not inherit transaction_safe for redeclarations; allow that explicit specializations differ

Open issues

• Exception handling might call std::terminate, which invokes a terminate handler. That terminate handler is a function pointer not declared transaction_safe, so there is a gap in the specification if std::terminate ends up being called inside an atomic transaction. The intersection of desirable and implementable semantics for this case is still under discussion.
• Initialization of variables with static storage duration.
• Atomic blocks that do not access shared memory locations should not receive or cause an inter-thread-happens-before edge, i.e. atomic blocks cannot be used as a replacement for fences. [Chandler Carruth in Issaquah (February 2014): this allows to remove hardware-level synchronization cost if the compiler can prove that an atomic block is entirely local.]
• At first sight, the math functions from <math.h> (e.g. "sin") are transaction-safe. However, they may need to inspect hardware state such as the current rounding mode that might make them unfit for transactional execution.
• investigate use of std::function inside transactions
• (postponed) Consider describing synchronized blocks entirely as-if taking a global mutex.

Resolved issues

• Under which circumstances is a lambda function (implicitly) declared transaction-safe? [It is declared tx-safe if its definition is (directly) safe and all invoked functions are tx-safe.] Do we want to allow an explicit transaction_safe/unsafe annotation? [Yes to the former.]
• Is the term "transaction-statement" still ok, or should that be renamed to "atomic-statement", in line with the (new) spelling of the keywords? Telco 2014-03-31: use "atomic block" and "transaction-safe".
• Allow conversion of "pointer to transaction-safe member function" to "pointer to member function"
• add "transaction_safe noinherit" for virtual functions
• std::exception is the base of the exception hierarchy. Should we declare its virtual what() function transaction_safe? [no; instead review definition of derived classes such as length_error] This has serious ripple effects to user code, in particular if that user code is totally unaware of transactions. Telco 2014-08-11 and 2014-09-08: introduce "maybe transaction_safe" for virtual functions, which is not viral, but accepts undefined behavior.
• For "composite pointer type" in 5 [expr], address that T might be "pointer to function" (not transaction-safe) vs. "pointer to transaction-safe function". This can be unified to "pointer to function" (not transaction-safe).
• Introduce a

  template<class T>
  class tx_exception : exception { ... };
  

  with a transaction-safe "what()" function and where "T" can be memcpy'd.
• add "template specialization can be tx-safe even when corresponding member of the template is not"

Section 1.10 [intro.multithread] Multi-threaded executions and data races

The start and the end of each synchronized block or atomic block is a full-expression (1.9 [intro.execution]). A synchronized block (6.x [stmt.sync]) or atomic block (6.x [stmt.tx]) that is not dynamically nested within another synchronized block or atomic block is called an outer block. [ Note: Due to syntactic constraints, blocks cannot overlap unless one is nested within the other. ] There is a global total order of execution for all outer blocks. If, in that total order, T1 is ordered before T2, then the end of T1 synchronizes with the start of T2.

Drafting notes: Together with 1.9p14, the first sentence ensures the appropriate (thread-local) sequencing. Inter-thread ordering is ensured by establishing a synchronizes-with relationship in the last sentence.

Synchronized and atomic blocks as well as certain Certain library calls synchronize with other synchronized blocks, atomic blocks, and library calls performed by another thread.

The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. [ Note: It can be shown that programs that correctly use mutexes, synchronized and atomic blocks, and memory_order_seq_cst operations to prevent all data races and use no other synchronization operations behave as if the operations executed by their constituent threads were simply interleaved, with each value computation of an object being taken from the last side effect on that object in that interleaving. This is normally referred to as "sequential consistency". However, this applies only to data-race-free programs, and data-race-free programs cannot observe most program transformations that do not change single-threaded program semantics. In fact, most single-threaded program transformations continue to be allowed, since any program that behaves differently as a result must perform an undefined operation. -- end note ]

[ Note: Due to the constraints on transaction safety (8.4.4 [dcl.fct.def.tx]), the following holds for a data-race-free program: If the start of an atomic block T is sequenced before an evaluation A, A is sequenced before the end of T, and A inter-thread happens before some evaluation B, then the end of T inter-thread happens before B. If an evaluation C inter-thread happens before that evaluation A, then C inter-thread happens before the start of T. These properties in turn imply that in any simple interleaved (sequentially consistent) execution, the operations of each atomic block appear to be contiguous in the interleaving. -- end note ]

Clause 2 [lex] Lexical conventions

In section 2.11 [lex.name] paragraph 2, add transaction_safe and transaction_safe_noinherit to the table.

In section 2.12 [lex.key], add the keywords synchronized, atomic_noexcept, atomic_cancel, and atomic_commit to the table.

Clause 4 [conv] Standard conversions

An lvalue of function type T can be converted to a prvalue of type "pointer to T." T". An lvalue of type "transaction-safe function" can be converted to a prvalue of type "pointer to function". The result is a pointer to the function. [ Footnote: ... ]

Drafting note: This ensures that overload resolution doesn't perceive dropping the "transaction-safe" as two conversions instead of just one. The same trick was applied for converting unscoped enumerations with fixed underlying type to the promoted underlying type (4.5p4).

4.14 [conv.tx] Transaction-safety conversion

A prvalue of type "pointer to transaction_safe function" can be converted to a prvalue of type "pointer to function". The result is a pointer to the function. A prvalue of type "pointer to member of type transaction_safe function" can be converted to a prvalue of type "pointer to member of type function". The result points to the member function.

Clause 5 [expr] Expressions

[ Note: ... ] The composite pointer type of two operands p1 and p2 having types T1 and T2, respectively, where at least one is a pointer or pointer to member type or std::nullptr_t, is:

• ...
• if T1 or T2 is "pointer to cv1 void" and the other type is "pointer to cv2 T", "pointer to cv12 void", where cv12 is the union of cv1 and cv2 ;
• if T1 is "pointer to transaction_safe function" and T2 is "pointer to function", where the function types are otherwise the same, T2, and vice versa;
• ...

lambda-declarator:
     ( parameter-declaration-clause ) mutableopt transaction_safeopt
            exception-specificationopt attribute-specifier-seqopt trailing-return-typeopt 

This function call operator or operator template is declared const (9.3.1) if and only if the lambda-expression's parameter-declaration-clause is not followed by mutable. It is neither virtual nor declared volatile. It is declared transaction_safe if and only if the lambda-expression's parameter-declaration-clause is followed by transaction_safe or, in a non-generic lambda-expression, it has a transaction-safe function definition (8.4.4 [dcl.fct.def.tx]). Any exception-specification specified on a lambda-expression applies to the corresponding function call operator or operator template. ...

The closure type for a non-generic lambda-expression with no lambda-capture has a public non-virtual non-explicit const transaction_safe conversion function to pointer to function with C++ language linkage (7.5 [dcl.link]) having the same parameter and return types as the closure type's function call operator. That pointer is a pointer to transaction-safe function if the function call operator is transaction-safe.

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

Recursive calls are permitted, except to the function named main (3.6.1)

Calling a function that is not transaction-safe (8.4.4 [dcl.fct.def.tx]) through a pointer to or lvalue of type "transaction-safe function" has undefined behavior.

Drafting note: This restriction might not be required if there is no defined way of obtaining a pointer to transaction-safe function from a pointer to (non-transaction-safe) function. One such way is precluded by the next change.

The inverse of any standard conversion sequence (Clause 4 [conv]) not containing an lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), function-to-pointer (4.3), null pointer (4.10), null member pointer (4.11), or boolean (4.12), or transaction-safety (4.14 [conv.tx]) conversion, can be performed explicitly using static_cast. ...

If at least one of the operands is a pointer, pointer conversions (4.10 [conv.ptr]), transaction-safety conversions (4.14 [conv.tx]), and qualification conversions (4.4 [conv.qual]) are performed on both operands to bring them to their composite pointer type (clause 5 [expr]). Comparing pointers is defined as follows: Before transaction-safety conversions, if one pointer is of type "pointer to function", the other is of type "pointer to transaction_safe function", and both point to the same function, it is unspecified whether the pointers compare equal. Otherwise, Two two pointers compare equal if they are both null, both point to the same function, or both represent the same address (3.9.2), otherwise they compare unequal.

• One or both of the second and third operands have pointer type; pointer conversions (4.10 [conv.ptr]), transaction-safety conversions (4.14 [conv.tx]), and qualification conversions (4.4 [conv.qual]) are performed to bring them to their composite pointer type (5 [expr]). ...
• ...

Clause 6 [stmt.stmt] Statements

statement:
      labeled-statement
      attribute-specifier-seqopt expression-statement
      attribute-specifier-seqopt compound-statement
      attribute-specifier-seqopt selection-statement
      attribute-specifier-seqopt iteration-statement
      attribute-specifier-seqopt jump-statement
      declaration-statement
      attribute-specifier-seqopt try-block
      synchronized-statement
      atomic-statement

Transfer out of an atomic block other than via an exception executes the end of the atomic block. [ Note: Colloquially, this is known as committing the transaction. For exceptions, see 15.2 [except.ctor]. -- end note ] Transfer out of a synchronized block (including via an exception) executes the end of the synchronized block.

6.x [stmt.sync] Synchronized statement

synchronized-statement:
       synchronized compound-statement

A synchronized statement is also called a synchronized block.

The start of the synchronized block is immediately before the opening { of the compound-statement. The end of the synchronized block is immediately after the closing } of the compound-statement.

A goto or switch statement shall not be used to transfer control into a synchronized block.

[ Example:

int f()
{
  static int i = 0;
  synchronized {
    printf("before %d\n", i);
    ++i;
    printf("after %d\n", i);
    return i;
  }
}

Each invocation of f (even when called from several threads simultaneously) retrieves a unique value (ignoring overflow). The output is guaranteed to comprise consistent before/after pairs. -- end example ]

6.x [stmt.tx] Atomic statement

atomic-statement:
       atomic_noexcept compound-statement
       atomic_cancel compound-statement
       atomic_commit compound-statement

An atomic statement is also called an atomic block. The program is ill-formed if the compound-statement is a transaction-unsafe statement (8.4.4 [dcl.fct.def.tx]).

The start of the atomic block is immediately before the opening { of the compound-statement. The end of the atomic block is immediately after the closing } of the compound-statement. [ Note: Thus, variables with automatic storage duration declared in the compound-statement are destroyed prior to reaching the end of the atomic block; see 6.6 [stmt.jump]. -- end note ]

A goto or switch statement shall not be used to transfer control into an atomic block.

[ Example:

int f()
{
  static int i = 0;
  atomic_noexcept {
    ++i;
    return i;
  }
}

Each invocation of f (even when called from several threads simultaneously) retrieves a unique value (ignoring overflow). -- end example ]

Section 7 [dcl.dcl] Declarations

... The asm declaration is conditionally-supported; its meaning is implementation-defined. [ Note: Typically it is used to pass information through the implementation to an assembler. -- end note ] It is implementation-defined which asm declarations are transaction-safe (8.4.4 [dcl.fct.def.tx]), if any.

7.6.6 [dcl.attr.sync] Attribute for optimization in synchronized blocks

The attribute-token optimize_for_synchronized specifies that a function definition should be optimized for invocation from a synchronized-statement (6.x [stmt.sync]). It shall appear at most once in each attribute-list and no attribute-argument-clause shall be present. The attribute may be applied to the declarator-id in a function declaration. The first declaration of a function shall specify the optimize_for_synchronized attribute if any declaration of that function specifies the optimize_for_synchronized attribute. If a function is declared with the optimize_for_synchronized attribute in one translation unit and the same function is declared without the optimize_for_synchronized attribute in another translation unit, the program is ill-formed; no diagnostic required.

[ Example:

// translation unit 1
[[optimize_for_synchronized]] int f(int);

void g(int x) {
  synchronized {
    int ret = f(x*x);
  }
}

// translation unit 2
#include <iostream>

extern int verbose;

[[optimize_for_synchronized]] int f(int x)
{
  if (x >= 0)
    return x;
  if (verbose > 1)
    std::cerr << "failure: negative x" << std::endl;
  return -1;
}

If the attribute were not present for f, which is not declared transaction_safe, a program might have to drop out of speculative execution in g's synchronized block every time when calling f, although that is only actually required for displaying the error message in the rare verbose error case. -- end example ]

Section 8 [dcl.decl] Declarators

parameters-and-qualifiers:
     ( parameter-declaration-clause ) cv-qualifier-seqopt
            ref-qualifieropt tx-qualifieropt exception-specificationopt attribute-specifier-seqopt

tx-qualifier:
     transaction_safe
     transaction_safe_noinherit

In a declaration T D where D has the form

    D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
         ref-qualifieropt tx-qualifieropt exception-specificationopt attribute-specifier-seqopt

and the type of the contained declarator-id in the declaration T D1 is "derived-declarator-type-list T", the type of the declarator-id in D is "derived-declarator-type-list transaction_safe_opt function of (parameter-declaration-clause) cv-qualifier-seq_opt ref-qualifier_opt returning T", where the optional transaction_safe is present if a tx-qualifier is present. The optional attribute-specifier-seq appertains to the function type.

In a declaration T D where D has the form

    D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
         ref-qualifieropt tx-qualifieropt exception-specificationopt attribute-specifier-seqopt trailing-return-type

and the type of the contained declarator-id in the declaration T D1 is "derived-declarator-type-list T", T shall be the single type-specifier auto. The type of the declarator-id in D is "derived-declarator-type-list transaction_safe_opt function of (parameter-declaration-clause) cv-qualifier-seq_opt ref-qualifier_opt returning trailing-return-type", where the optional transaction_safe is present if a tx-qualifier is present. The optional attribute-specifier-seq appertains to the function type.

... After determining the type of each parameter, any parameter of type "array of T" or "transaction_safe_opt function returning T" is adjusted to be "pointer to T" or "pointer to transaction_safe_opt function returning T," respectively. ...

... The return type, the parameter-type-list, the ref-qualifier, and the cv-qualifier-seq, and the transaction_safe qualifier, but not the default arguments (8.3.6 [dcl.fct.default]) or the exception specification (15.4 [except.spec]), are part of the function type. ...

The transaction_safe_noinherit qualifier may only appear in a function declarator that declares a virtual function in a class definition. A virtual function declared with the transaction_safe_noinherit qualifier is considered to be declared transaction_safe. [ Note: A virtual function so declared can be overridden by a function that is not transaction-safe (see 10.3 class virtual), but calling such an overrider from a synchronized or atomic block causes undefined behavior (see 5.2.2 expr.call). -- end note ] All declarations of a function shall be declared transaction_safe if any declaration of that function is declared transaction_safe, except that the declaration of an explicit specialization (14.7.3 [temp.expl.spec]) may differ from the declaration that would be instantiated from the template; no diagnostic is required if conflicting declarations appear in different translation units.

The declarator in a function-definition shall have the form

         D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
               ref-qualifieropt exception-specificationopt attribute-specifier-seqopt 
               parameters-and-qualifiers trailing-return-typeopt

[ Drafting note: This is intended to reduce the grammar redundancies around function declarators. ]

8.4.4 [dcl.fct.def.tx] Transaction-safe function definitions

An expression is transaction-unsafe if it contains any of the following as a potentially-evaluated subexpression (3.2 [basic.def.odr]):

• an lvalue-to-rvalue conversion (4.1 [conv.lval]) applied to a volatile glvalue [ Note: referring to a volatile object through a non-volatile glvalue has undefined behavior; see 7.1.6.1 [dcl.type.cv] -- end note ],
• an expression that modifies an object through a volatile glvalue,
• the creation of a temporary object of volatile-qualified type or with a subobject of volatile-qualified type,
• a function call (5.2.2 expr.call) whose postfix-expression is an id-expression that names a non-virtual function that is not transaction-safe,
• an implicit call of a non-virtual function that is not transaction-safe, or
• any other call of a function, where the function type is not "transaction_safe function".

A statement is a transaction-unsafe statement if it lexically directly contains one of the following (including evaluations of default argument expressions in function calls and evaluations of brace-or-equal-initializers for non-static data members in aggregate initialization (8.5.1 dcl.init.aggr), but ignoring the declaration of default argument expressions, local classes, and the compound-statement of a lambda-expression):

• a full-expression that is transaction-unsafe,
• an asm-definition (7.4 [dcl.asm]) that is not transaction-safe,
• a declaration of a variable of volatile-qualified type or with a subobject of volatile-qualified type, or
• a statement that is transaction-unsafe (recursively).

A function has a transaction-safe definition if none of the following applies:

• any parameter has volatile-qualified type or has a subobject of volatile-qualified type,
• its compound-statement (including the one in the function-try-block, if any) is a transaction-unsafe statement,
• for a constructor or destructor, the corresponding class has a volatile non-static data member, or
• for a constructor, a full-expression in a mem-initializer or an assignment-expression in a brace-or-equal-initializer that is not ignored (12.6.2 [class.base.init]) is transaction-unsafe.

[ Example:

  extern volatile int * p = 0;
  struct S {
    virtual ~S();
  };

  int f() transaction_safe {
    int x = 0;   // ok: not volatile
    p = &x;      // ok: the pointer is not volatile
    int i = *p;      // error: read through volatile glvalue
    S s;         // error: invocation of unsafe destructor
  }

-- end example ]

A function declared transaction_safe shall have a transaction-safe definition.

A function is transaction-safe if it is declared transaction_safe (see 8.3.5 [dcl.fct]), or if it is a non-virtual function defined before its first odr-use (3.2 [basic.def.odr]) and it has a transaction-safe function definition. A specialization of a function template or of a member function of a class template, where the function or function template is not declared transaction_safe, but defined before the first point of instantiation, is transaction-safe if and only if it satisfies the conditions for a transaction-safe function definition. [ Note: Even if a function is implicitly transaction-safe, its function type is not changed to "transaction_safe function". -- end note ]

While determining whether a function f is transaction-safe, f is assumed to be transaction-safe for directly and indirectly recursive calls. [ Example:

  int f(int x) {    // is transaction-safe
    if (x <= 0)
      return 0;
    return x + f(x-1);
  }

-- end example ]

Section 10.3 [class.virtual] Virtual functions

A function that overrides a function declared transaction_safe, but not transaction_safe_noinherit, is implicitly considered to be declared transaction_safe. [ Note: Its definition is ill-formed unless it actually has a transaction-safe definition (8.4.4 dcl.fct.def.tx). -- end note ] A function declared transaction_safe_noinherit that overrides a function declared transaction_safe (but not transaction_safe_noinherit) is ill-formed. [ Example:

struct B {
  virtual void f() transaction_safe;
  virtual ~B() transaction_safe_noinherit;
};

// pre-existing code
struct D1 : B
{
  void f() override { }   // ok
  ~D1() override { }   // ok
};

struct D2 : B
{
  void f() override { std::cout << "D2::f" << std::endl; }
       // error: transaction-safe f has transaction-unsafe definition
  ~D2() override { std::cout << "~D2" << std::endl; }     // ok
};

struct D3 : B
{
  void f() transaction_safe_noinherit override;
         // error: B::f() is transaction_safe
};

int main()
{
  D2 * d2 = new D2;
  B * b2 = d2;
  atomic_commit {
    B b;        // ok
    D1 d1;      // ok
    B& b1 = d1;
    D2 x;       // error: destructor of D2 is not transaction-safe
    b1.f();     // ok, calls D1::f()
    delete b2;  // undefined behavior: calls unsafe destructor of D2
  }
}

-- end example ]

Clause 13 [over] Overloading

Certain function declarations cannot be overloaded:

• Function declarations that differ only in the return type cannot be overloaded.
• Function declarations that differ only in the presence or absence of a tx-qualifier cannot be overloaded.
• ...

• Conversion: Transaction-safety conversion
• Category: Lvalue transformation
• Rank: Exact Match
• Subclause: 4.14 [conv.tx]

... The function selected is the one whose type is identical to the function type of the target type required in the context. A function with type F is selected for the function type FT of the target type required in the context if F (after possibly applying the transaction-safety conversion (4.14 [conv.tx])) is identical to FT. [ Note: ... ]

[ Note: There are no standard conversions (Clause 4) of one pointer-to-function type into another. In particular, even Even if B is a public base of D, we have

D* f();
B* (*p1)() = &f;     // error
void g(D*);
void (*p2)(B*) = &g; // error

]

Clause 14 [temp] Templates

A non-type template-parameter of type "array of T" or "transaction_safe_opt function returning T" is adjusted to be of type "pointer to T" or "pointer to transaction_safe_opt function returning T", respectively. [ Example: ... ]

An explicit specialization of a function template or of a member function of a class template can be declared transaction_safe (8.3.5 [dcl.fct.def]) independently of whether the corresponding template entity is declared transaction_safe. [ Example:

template<class T>
void f(T) transaction_safe;

template<>
void f(bool);   // not transaction-safe

-- end example ]

A specialization instantiated from a function template or from a member function of a class template, where the function template or member function is declared transaction_safe, shall have a transaction-safe definition (8.4.4 [dcl.fct.def.tx]).

... However, there are three cases that allow a difference:

• ...
• The transformed A can be another pointer or pointer to member type that can be converted to the deduced A via a qualification conversion (4.4 c[onv.qual]) or a transaction-safety conversion (4.14 [conv.tx]).
• ...

Clause 15 [except] Exception handling

... Evaluating a throw-expression with an operand throws an exception; the type of the exception object is determined by removing any top-level cv-qualifiers from the static type of the operand and adjusting the type from "array of T" or "transaction_safe_opt function returning T" to "pointer to T" or "pointer to transaction_safe_opt function returning T," respectively.

Section 15.2 [except.ctor] Constructors, and destructors, and atomic blocks

As control passes from the point where an exception is thrown to a handler, destructors are invoked for all automatic objects constructed since the try block was entered yet still in scope (6.6 [stmt.jump], and atomic blocks are terminated (see below) where the start, but not the end of the block, was executed since the try block was entered (6.x [stmt.tx]). The automatic objects are destroyed and atomic blocks are terminated in the reverse order of the completion of their construction and the execution of the start of the atomic blocks.

An atomic block is terminated according to its kind, as follows: Terminating an atomic_commit block executes the end of the atomic block (1.10 intro.multithread) and has no further effect. [ Note: That is, control exits the atomic block after causing inter-thread synchronization. -- end note ] Terminating an atomic_cancel block, if the type of the current exception does not support transaction cancellation, or terminating an atomic_noexcept block, invokes std::abort (18.5 [support.start.term]). [ Footnote: If the effects of the atomic block become visible to other threads prior to program termination, some thread might make progress based on broken state, making debugging harder. -- end footnote ]. Terminating an atomic_cancel block, if the type of the current exception supports transaction cancellation, cancels the atomic block by performing the following steps, in order:

• A temporary object is copy-initialized (8.5 [dcl.init]) from the exception object. [ Note: if the initialization terminates via an exception, std::terminate is called (15.1 [except.throw]). -- end note ]
• The values of all memory locations in the program that were modified by side effects of the operations of the atomic block, except those occupied by the temporary object, are restored to the values they had at the time the start of the atomic block was executed.
• The end of the atomic block is executed. [ Note: This causes inter-thread synchronization. -- end note ]
• The temporary object is used as the exception object in the subsequent stack unwinding.

[ Note: A cancelled atomic block, although having no visible effect, still participates in data races (1.10 [intro.multithread]). -- end note ]

Non-volatile scalar types support transaction cancellation, as do those types specified as doing so in clauses 18 and 19.

A handler is a match for an exception object of type E if

• ...
• the handler is of type cv T or const T& where T is a pointer type and E is a pointer type that can be converted to T by either or both of one or more of
  • a standard pointer conversion (4.10 [conv.ptr]) not involving conversions to pointers to private or protected or ambiguous classes
  • a qualification conversion (4.4 [conv.qual])
  • a transaction-safety conversion (4.14 [conv.tx])
• ...

... A type cv T, "array of T", or "transaction_safe_opt function returning T" denoted in an exception-specification is adjusted to type T, "pointer to T", or "pointer to transaction_safe_opt function returning T", respectively.

Standard library

Drafting note: The following guidelines were employed for transaction-safety requirements in the standard library, roughly oriented on the guidelines for constexpr and noexcept:

• If a function can unconditionally satisfy its contract without invoking user-defined code, it is declared transaction_safe. Functions declared noexcept strongly hint in that direction. Example: size() member function of containers.
• If a function is expected to call potentially user-defined code, that function is specified in prose to be transaction-safe under the condition that all of the potentially invoked user-defined functions are transaction-safe. Example: A copy constructor of a container is only transaction-safe if all required functions of the allocator are transaction-safe and if all required functions for the contained type T are transaction-safe, where "required function" is defined by the respective requirements tables.
• There is no code-level specification of conditional transaction-safety. When simply calling such a function, there is no issue, because transaction-safety is inferred from the definition.

• ...
• Synchronization: the synchronization operations (1.10) applicable to the function
• Transactions: the transaction-related properties of the function, in particular whether the function is transaction-safe (8.4.4 [dcl.fct.def.tx])
• ...

All operations that are transaction-safe on X shall be transaction-safe on Y.

17.6.5.16 [lib.txsafe] Transaction safety

This standard explicitly requires that certain standard library functions are transaction-safe (8.4.4 dcl.fct.def.tx). An implementation shall not declare any standard library function signature as transaction_safe except for those where it is explicitly required.

[[noreturn]] void abort(void) transaction_safe noexcept ;

The function abort() has additional behavior in this International Standard:

• The program is terminated without executing destructors for objects of automatic, thread, or static storage duration and without calling functions passed to atexit() (3.6.3).

... The library versions of the global allocation and deallocation functions are declared transaction_safe (8.3.5 dcl.fct).

The classes bad_alloc, bad_array_length, and bad_array_new_length support transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

In 18.6.2.1 [bad.alloc] and 18.6.2.2 [new.badlength], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe_noinherit to the declaration of each virtual member function.

The class bad_cast defines the type of objects thrown as exceptions by the implementation to report the execution of an invalid dynamic-cast expression (5.2.7 [expr.dynamic.cast]). The class supports transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

In 18.7.2 [bad.cast], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe_noinherit to the declaration of each virtual member function.

The class bad_typeid defines the type of objects thrown as exceptions by the implementation to report a null pointer in a typeid expression (5.2.8 [expr.typeid]). The class supports transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

In 18.7.3 [bad.typeid], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe_noinherit to the declaration of each virtual member function.

In 18.8.1 [exception] and 18.8.2 [bad.exception], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe_noinherit to the declaration of each virtual member function.

The class bad_exception defines the type of objects thrown as described in (15.5.2 [except.unexpected]). 15.5.2 [except.unexpected]. The class supports transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

The function signature longjmp(jmp_buf jbuf, int val) has more restricted behavior in this International Standard. A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would invoke any non-trivial destructors for any automatic objects, or would transfer out of a synchronized block (6.x [stmt.sync]) or atomic block (6.x [stmt.tx]).

... These exceptions are related by inheritance. The exception classes support transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ].

  template<class T> class tx_exception;

In 19.2 [std.exceptions], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe_noinherit to the declaration of each virtual member function.

Class template tx_exception

  namespace std {
    template<class T>
    class tx_exception : public runtime_error {
    public:
       explicit tx_exception(T value) transaction_safe;
       tx_exception(T value, const char* what_arg) transaction_safe;
       tx_exception(T value, const string& what_arg) transaction_safe;
       T get() const transaction_safe;      
    };
  }

A specialization of tx_exception supports transaction cancellation (15.2 [except.ctor]). If T is not a trivially copyable type (3.9 [basic.types]), the program is ill-formed.

tx_exception(T value) transaction_safe;

Effects: Constructs an object of class tx_exception.

Postcondition: The result of calling get() is equivalent to value.

tx_exception(T value, const char * what_arg) transaction_safe;

Effects: Constructs an object of class tx_exception.

Postcondition: strcmp(what(), what_arg) == 0 and the result of calling get() is equivalent to value.

tx_exception(T value, const string& what_arg) transaction_safe;

Effects: Constructs an object of class tx_exception.

Postcondition: strcmp(what(), what_arg.c_str()) == 0 and the result of calling get() is equivalent to value.

Change in 20.7.3.2 [pointer.traits.functions]:

static pointer pointer_traits::pointer_to(see below r);
static pointer pointer_traits<T*>::pointer_to(see below r) transaction_safe noexcept;

...
Transactions: The first member function is transaction-safe if the invoked member function of Ptr is transaction-safe.

void* align(std::size_t alignment, std::size_t size,
    void*& ptr, std::size_t& space) transaction_safe;

A function in this section is transaction-safe if the invoked function (as specified below) is transaction-safe.

In 20.7.9.1 [allocator.members], add "transaction_safe" to the declarations of the following member functions: address (twice), allocate, deallocate, max_size.

template <class U, class... Args>
  void construct(U* p, Args&&... args);

Effects: ::new((void *)p) U(std::forward(args)...)
Transactions: Transaction-safe if the invoked constructor of U is transaction-safe.

template <class U>
  void destroy(U* p);

Effects: p->~U()
Transactions: Transaction-safe if the destructor of U is transaction-safe.

template <class T>
  pair<T*, ptrdiff_t> get_temporary_buffer(ptrdiff_t n) transaction_safe noexcept;

...

template <class T> void return_temporary_buffer(T* p) transaction_safe;

... In the following algorithms, if an exception is thrown there are no effects. Each of the following functions is transaction-safe if the constructor invoked via the placement allocation function is transaction-safe.

template <class T> T* addressof(T& r) transaction_safe noexcept;

The contents are the same as the Standard C library header <stdlib.h>, with the following changes:

The functions are transaction-safe.

Change in 20.7.13 [c.malloc] paragraph 7:

The contents are the same as the Standard C library header <string.h>, with the change to memchr() specified in 21.8 [c.strings]. The functions are transaction-safe.

[ Drafting note: This covers memchr, memcmp, memcpy, memmove, and memset. ]

... The template parameter T of unique_ptr may be an incomplete type. Each of the functions in this section is transaction-safe if either no functions are called or all functions called are transaction-safe.

All functions in this Clause are transaction-safe if the required operations on the supplied allocator (17.6.3.5 [allocator.requirements]) and character traits (21.2.1 [char.traits.require]) are transaction-safe.

In 21.4.3 [string.iterators], 21.4.4 [string.capacity], 21.4.5 [string.access], add "transaction_safe" to the declarations of all member functions.

Unless unconditionally specified to be transaction-safe, a function in this Clause is transaction-safe if all required operations are transaction-safe. [ Note: This includes operations on the element type, on std::allocator_traits, and on Compare, Pred, or Hash objects, depending on the respective function. -- end note ]

all functions required for the iterator category are transaction-safe

... If the container is empty, then begin() == end().

The member functions begin, end, cbegin, cend, size, max_size, and empty are transaction-safe.

If the iterator type of a container belongs to the bidirectional or random access iterator categories (24.2 [iterator.requirements]), the container is called reversible and satisfies the additional requirements in Table 97.

[ table ]

The member functions rbegin, rend, crbegin, and crend are transaction-safe.

[ table ]

The member functions front, back, and at as well as the indexing operation a[n] are transaction-safe.

The member function at() provides bounds-checked access to container elements. at() throws out_of_range if n >= a.size().

The behavior of a program that uses operator== or operator!= on unordered containers is undefined unless the Hash and Pred function objects respectively have the same behavior for both containers and the equality comparison operator for Key is a refinement [ Footnote: ... ] of the partition into equivalent-key groups produced by Pred.

The member functions bucket_count, max_bucket_count, bucket_size, begin, end, cbegin, cend, load_factor, and max_load_factor are transaction-safe.

In 23.3.3.1 [deque.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], front, back.

In 23.3.4.1 [forwardlist.overview] and 23.3.4.6 [forwardlist.ops], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of max_size, empty, front, splice_after, and reverse.

In 23.3.6.1 [vector.overview], 23.3.6.3 [vector.capacity], and 23.3.6.4 [vector.data], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, capacity, empty, operator[], front, back, data.

In 23.3.7 [vector.bool], add "transaction_safe" to the declarations of all variants of the begin and end member functions, to the declarations of size, max_size, capacity, empty, operator[], front, back, and flip, and to the static member function swap.

In 23.4.4.1 [map.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.4.5.1 [multimap.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.4.6.1 [set.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.4.7.1 [multiset.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.5.4.1 [unord.map.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

In 23.5.5.1 [unord.multimap.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

In 23.5.6.1 [unord.set.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

In 23.5.7.1 [unord.multiset.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

Add in 23.6.1 [container.adaptors.general] after paragraph 3:

For container adaptors, no swap function throws an exception unless that exception is thrown by the swap of the adaptor's Container or Compare object (if any).

A member function f of a container adaptor is transaction-safe if the required member functions of the adaptor's Container and Compare (if any) are transaction-safe, as given by the specification for f.

Since only random access iterators provide + and - operators, the library provides two function templates advance and distance. These function templates use + and - for random access iterators (and are, therefore, constant time for them); for input, forward and bidirectional iterators they use ++ to provide linear time implementations. A specialization of a function template specified in this Clause is transaction-safe if all operations required for the template arguments are transaction-safe.

Class template reverse_iterator is an iterator adaptor that iterates from the end of the sequence defined by its underlying iterator to the beginning of that sequence. The fundamental relation between a reverse iterator and its corresponding iterator i is established by the identity: &*(reverse_iterator(i)) == &*(i - 1). A member function specified in this Clause is transaction-safe if all operations required for the template argument of reverse_iterator are transaction-safe.

A function or function template specified in this Clause is transaction-safe if all operations required for the template arguments are transaction-safe.

A member function specified in this Clause is transaction-safe if all operations required for the template arguments are transaction-safe.

In addition to being available ..., and <vector>. A specialization of a function template specified in this Clause is transaction-safe if all required operations (as specified by the Returns element) are transaction-safe.

Add a new 25.1 [algorithms.general] paragraph 13:

A specialization of a function template specified in this Clause is transaction-safe if all functions and operations required for the template arguments are transaction-safe. [ Example: The fill function (25.3.6 [alg.fill]) is transaction-safe if all required operations of its ForwardIterator template argument are transaction-safe and if T's copy assignment operator is transaction-safe. -- end example ]

A specialization of a function template specified in this Clause is transaction-safe if all functions and operations required for the template arguments are transaction-safe (see 25.1 [algorithms.general]).

The contents of these headers are the same as the Standard C library headers <math.h> and <stdlib.h> respectively, with the following changes:

The functions from <stdlib.h>, including the additional overloads in <cstdlib> (see below), but excluding rand and srand, are transaction-safe.

[ Drafting note: This covers abs, ldiv, rand, div, llabs, srand, labs, and lldiv.]