cpp/language/transactional memory

Transactional memory is a concurrency synchronization mechanism that combines groups of statements in transactions, that are
 * atomic (either all statements occur, or nothing occurs)
 * isolated (statements in a transaction may not observe half-written writes made by another transaction, even if they execute in parallel)

Typical implementations use hardware transactional memory where supported and to the limits that it is available (e.g. until the changeset is saturated) and fall back to software transactional memory, usually implemented with optimistic concurrency: if another transaction updated some of the variables used by a transaction, it is silently retried. For that reason, retriable transactions ("atomic blocks") can only call transaction-safe functions.

Note that accessing a variable in a transaction and out of a transaction without other external synchronization is a data race.

If feature testing is supported, the features described here are indicated by the macro constant with a value equal or greater.

Synchronized blocks
Executes the as if under a global lock: all outermost synchronized blocks in the program execute in a single total order. The end of each synchronized block synchronizes with the beginning of the next synchronized block in that order. Synchronized blocks that are nested within other synchronized blocks have no special semantics.

Synchronized blocks are not transactions (unlike the atomic blocks below) and may call transaction-unsafe functions.

Leaving a synchronized block by any means (reaching the end, executing goto, break, continue, or return, or throwing an exception) exits the block and synchronizes-with the next block in the single total order if the exited block was an outer block. The behavior is undefined if std is used to exit a synchronized block.

Entering a synchronized block by goto or switch is not allowed.

Although synchronized blocks execute as-if under a global lock, the implementations are expected to examine the code within each block and use optimistic concurrency (backed up by hardware transactional memory where available) for transaction-safe code and minimal locking for non-transaction safe code. When a synchronized block makes a call to a non-inlined function, the compiler may have to drop out of speculative execution and hold a lock around the entire call unless the function is declared (see below) or the attribute  (see below) is used.

Atomic blocks
@1@ If an exception is thrown, is called. @2@ If an exception is thrown, is called, unless the exception is one of the exceptions used for transaction cancellation (see below) in which case the transaction is cancelled: the values of all memory locations in the program that were modified by side effects of the operations of the atomic block are restored to the values they had at the time the start of the atomic block was executed, and the exception continues stack unwinding as usual. @3@ If an exception is thrown, the transaction is committed normally.

The exceptions used for transaction cancellation in blocks are std, std, std, std, std, std and all standard library exceptions derived from it, and the special exception type.

The in an atomic block is not allowed to execute any expression or statement or call any function that isn't  (this is a compile time error).

Leaving an atomic block by any means other than exception (reaching the end, goto, break, continue, return) commits the transaction. The behavior is undefined if std is used to exit an atomic block.

Transaction-safe functions
A function can be explicitly declared to be transaction-safe by using the keyword in its declaration.

In a declaration, it appears either immediately after the capture list, or immediately after the (keyword  (if one is used).

If a function that is not transaction-safe is called through a reference or pointer to a transaction-safe function, the behavior is undefined.

Pointers to transaction-safe functions and pointers to transaction-safe member functions are implicitly convertible to pointers to functions and pointers to member functions respectively. It is unspecified if the resulting pointer compares equal to the original.

Transaction-safe virtual functions
If the final overrider of a function is not declared, calling it in an atomic block is undefined behavior.

Standard library
Besides introducing the new exception template, the transactional memory technical specification makes the following changes to the standard library:


 * makes the following functions explicitly :
 * std, std, std, std, std, global default operator new, global default operator delete, std if the invoked constructor is transaction-safe, std if the invoked destructor is transaction-safe, std, std, std, std, each non-virtual member function of all exception types that support transaction cancellation (see  above)


 * makes the following functions explicitly
 * each virtual member function of all exception types that support transaction cancellation (see above)


 * requires that all operations that are transaction-safe on an X are transaction-safe on

Attributes
The attribute may be applied to a declarator in a function declaration and must appear on the first declaration of the function.

If a function is declared in one translation unit and the same function is declared without  in another translation unit, the program is ill-formed; no diagnostic required.

It indicates that a the function definition should be optimized for invocation from a statement. In particular, it avoids serializing synchronized blocks that make a call to a function that is transaction-safe for the majority of calls, but not for all calls (e.g. hash table insertion that may have to rehash, allocator that may have to request a new block, a simple function that may rarely log).

GCC assembly without the attribute: the entire function is serialized insert_key(char*, char*): subq	$8, %rsp movq	%rsi, %rdx movq	%rdi, %rsi movl	$hash, %edi call	Hash::insert(char*, char*) testb	%al, %al je	.L20 movb	$1, rehash(%rip) mfence .L20: addq	$8, %rsp ret GCC assembly with the attribute: transaction clone for insert_key(char*, char*): subq	$8, %rsp movq	%rsi, %rdx movq	%rdi, %rsi movl	$hash, %edi call	transaction clone for Hash::insert(char*, char*) testb	%al, %al je	.L27 xorl	%edi, %edi call	_ITM_changeTransactionMode # Note: this is the serialization point movb	$1, rehash(%rip) mfence .L27: addq	$8, %rsp ret

Compiler support
This technical specification is supported by GCC as of version 6.1 (requires to enable). An older variant of this specification was supported in GCC as of 4.7.