Transactional Synchronization Extensions (TSX) is an extension to the x86 instruction set architecture that adds hardware transactional memory support, speeding up execution of multi-threaded software through lock elision.
TSX was documented by Intel in February 2012, and debuted in June 2013 on Intel's microprocessors based on the Haswell microarchitecture. Haswell processors below 45xx as well as R-series and K-series (with unlocked multiplier) SKUs do not support TSX.
TSX provides two software interfaces for designating code regions for transactional execution. Hardware Lock Elision (HLE) is an instruction prefix-based interface designed to be backward compatible with processors without TSX support. Restricted Transactional Memory (RTM) is a new instruction set interface that provides greater flexibility for programmers.
TSX enables optimistic execution of transactional code regions. The hardware monitors multiple threads for conflicting memory accesses, while aborting and rolling back transactions that cannot be successfully completed. Mechanisms are provided for software to detect and handle failed transactions.
In other words, lock elision through transactional execution uses memory transactions as a fast path where possible, while the slow (fallback) path is still a normal lock.
Hardware Lock Elision (HLE) adds two new instruction prefixes,
XRELEASE. These two prefixes reuse the opcodes of the existing
REPE prefixes (
F3H). On processors that do not support TSX,
REPE prefixes are ignored on instructions for which the
XRELEASE are valid, thus enabling backward compatibility.
XACQUIRE prefix hint can only be used with the following instructions with an explicit
XCHG instruction can be used without the
LOCK prefix as well.
XRELEASE prefix hint can be used both with the instructions listed above, and with the
MOV mem, reg and
MOV mem, imm instructions.
HLE allows optimistic execution of a critical section by eliding the write to a lock, so that the lock appears to be free to other threads. A failed transaction results in execution restarting from the
XACQUIRE-prefixed instruction, but treating the instruction as if the
XACQUIRE prefix were not present.
Restricted Transactional Memory (RTM) is an alternative implementation to HLE which gives the programmer the flexibility to specify a fallback code path that is executed when a transaction cannot be successfully executed.
RTM adds three new instructions:
XEND instructions mark the start and the end of a transactional code region; the
XABORT instruction explicitly aborts a transaction. Transaction failure redirects the processor to the fallback code path specified by the
XBEGIN instruction, with the abort status returned in the
|0||Set if abort caused by
|1||If set, the transaction may succeed on a retry. This bit is always clear if bit 0 is set.|
|2||Set if another logical processor conflicted with a memory address that was part of the transaction that aborted.|
|3||Set if an internal buffer overflowed.|
|4||Set if debug breakpoint was hit.|
|5||Set if an abort occurred during execution of a nested transaction.|
TSX provides a new
XTEST instruction that returns whether the processor is executing a transactional region.
Intel's TSX specification describes how the transactional memory is exposed to programmers, but withholds details on the actual transactional memory implementation. Intel specifies in its developer's and optimization manuals that Haswell maintains both read-sets and write-sets at the granularity of a cache line, tracking addresses in the L1 data cache of the processor. Intel also states that data conflicts are detected through the cache coherence protocol.
Haswell's L1 data cache has an associativity of eight. This means that in this implementation, a transactional execution that writes to nine distinct locations mapping to the same cache set, will abort. However, due to micro-architectural implementations, this does not mean that fewer accesses to the same set are guaranteed to never abort. Additionally, in CPU configurations with Hyper-Threading Technology, the L1 cache is shared between the two threads on the same core, so operations in a sibling logical processor of the same core can cause evictions.
Independent research points into Haswell’s transactional memory most likely being a deferred update system using the per-core caches for transactional data and register checkpoints. In other words, Haswell is more likely to use the cache-based transactional memory system, as it is a much less risky implementation choice. On the other hand, Intel's future microarchitectures (Skylake or later) might be combinining this cache-based approach with using memory ordering buffer (MOB) for the same purpose, possibly also providing multi-versioned transactional memory that is more amenable to speculative multithreading.