Restricted Transactional Memory (RTM) provides a software interface for transactional execution. RTM provides three new instructions—
XABORT—for programmers to start, commit, and abort transactional execution.
The programmer uses the
XBEGIN instruction to specify the start of the transactional code region and the
XEND instruction to specify the end of the transactional code region. The
XBEGIN instruction takes an operand that provides a relative offset to the fallback instruction address if the RTM region could not be successfully executed transactionally.
A processor may abort RTM transactional execution for many reasons. The hardware automatically detects transactional abort conditions and restarts execution from the fallback instruction address with the architectural state corresponding to that at the start of the
XBEGIN instruction and the
EAX register updated to describe the abort status.
XABORT instruction allows programmers to abort the execution of an RTM region explicitly. The
XABORT instruction takes an 8-bit immediate argument that is loaded into the
EAX register becoming available to software following an RTM abort.
RTM instructions do not have any data memory location associated with them. While the hardware provides no guarantees as to whether an RTM region will ever successfully commit transactionally, most transactions that follow the recommended guidelines are expected to successfully commit transactionally.
Programmers must always provide an alternative code sequence in the fallback path to guarantee the code completes execution. This may be as simple as acquiring a lock and executing the specified code region non-transactionally. Further, a transaction that always aborts on a given implementation may complete transactionally on a future implementation. Therefore, programmers must ensure the code paths for the transactional region and the alternative code sequence are functionally tested.
Detection of RTM Support
A processor supports RTM execution if CPUID.07H.EBX.RTM [bit 11] = 1. An application must check if the processor supports RTM before it uses the RTM instructions (
XABORT). These instructions will generate a #UD exception when used on a processor that does not support RTM.
RTM Abort Status Definition
RTM uses the
EAX register to communicate abort status to software. Following an RTM abort the
EAX register has the following definition.
Set if abort caused by
If set, the transaction may succeed on a retry. This bit is always clear if bit '0' is set.
Set if another logical processor conflicted with a memory address that was part of the transaction that aborted.
Set if an internal buffer overflowed.
Set if a debug breakpoint was hit.
Set if an abort occurred during execution of a nested transaction.
EAX abort status for RTM only provides the cause for aborts. It does not by itself encode whether an abort or commit occurred for the RTM region. The value of
EAX can be '0' following an RTM abort. For example, a CPUID instruction when used inside an RTM region causes a transactional abort and may not satisfy the requirements for setting any of the
EAX bits. This may result in an
EAX value of '0'.
RTM Memory Ordering
A successful RTM commit causes all memory operations in the RTM region to appear to execute atomically. A successfully committed RTM region consisting of an
XBEGIN followed by an
XEND, even with no memory operations in the RTM region, has the same ordering semantics as a
LOCK prefixed instruction. The
XBEGIN instruction does not have fencing semantics. However, if an RTM execution aborts, all memory updates from within the RTM region are discarded and never made visible to any other logical processor.