# Restricted Transactional Memory Overview

Restricted Transactional Memory (RTM) provides a software interface for transactional execution. RTM provides three new instructions— `XBEGIN`, `XEND`, and `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.

The `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 (`XBEGIN`, `XEND`, `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.

`EAX` register bit position | Meaning
--- | ---
0 | Set if abort caused by `XABORT` instruction.
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 a debug breakpoint was hit.
5 | Set if an abort occurred during execution of a nested transaction.
23:6 | Reserved.
31:24 | `XABORT` argument (only valid if bit '0' set, otherwise reserved).

The `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.

Parent topic: Intrinsics for Restricted Transactional Memory Operations

## See Also

Intel® Transactional Synchronization Extensions Programming Considerations