AMBA AXI · Module 9

Exclusive Access

AXI's atomic read-modify-write mechanism — the exclusive monitor, load-/store-exclusive semantics, the EXOKAY (success) vs OKAY (failure) responses, and the size/alignment constraints, mapping to LDREX/STREX and load-linked/store-conditional.

Everywhere else in AXI, the master must build ordering and atomicity itself (Chapters 9.1–9.2). Exclusive access is the one place AXI provides a hardware mechanism for atomic read-modify-write — the basis of locks, semaphores, and atomic counters. It's AXI's form of load-exclusive / store-exclusive (ARM's LDREX/STREX, or load-linked/store-conditional elsewhere): read a location exclusively, modify the value, then attempt an exclusive write that succeeds only if nobody else touched the location in between. The machinery is the exclusive monitor and the EXOKAY vs OKAY response distinction. This chapter covers the sequence, the monitor's state machine, the success/failure semantics, and the constraints — building on AxLOCK from Chapter 6.4.

1. The Exclusive Sequence

An atomic update is two transactions marked exclusive (AxLOCK = 1):

Load-exclusive (exclusive read): the manager issues a read with ARLOCK = 1. A hardware exclusive monitor records the location and returns EXOKAY to confirm the location is being monitored. The manager now has the current value.
(software modifies the value)
Store-exclusive (exclusive write): the manager issues a write with AWLOCK = 1 to the same location. The monitor checks whether any other agent wrote that location since the exclusive read:
- No intervening write → the write succeeds, memory updates, and BRESP = EXOKAY. The read-modify-write was atomic.
- Intervening write → the write fails: memory is not updated, and BRESP = OKAY. Software sees OKAY (not EXOKAY) and retries the whole sequence.

The key inversion to remember: on a store-exclusive, EXOKAY = success, OKAY = failure — the "normal" response means the atomic attempt lost the race.

Figure 1 — the exclusive sequence. Load-exclusive (ARLOCK=1) sets the monitor and returns EXOKAY. After the modify, store-exclusive (AWLOCK=1) to the same location returns EXOKAY if no one wrote it in between (atomic success), or OKAY if an intervening write cleared the monitor (failure → software retries). EXOKAY means success; OKAY on a store-exclusive means it failed.

2. The Exclusive Monitor State Machine

The monitor is a small state machine per monitored location (conceptually):

Figure 2 — the exclusive monitor state machine. From Open, a load-exclusive sets the monitor (→ Monitoring, returns EXOKAY). From Monitoring, a store-exclusive while still monitored writes and returns EXOKAY (success → Open); but an intervening write by another agent moves to Cleared, after which a store-exclusive does not write and returns OKAY (failure → Open, software retries).

A subordinate that doesn't implement a monitor for a region returns OKAY to an exclusive read (signalling exclusivity isn't supported there) — so software must check the read response too. Monitors come in two flavors: a local monitor at a subordinate (for accesses that stay within it) and a global monitor in the interconnect (for locations multiple masters can reach), the latter needed for cross-master atomicity.

3. On the Wire

The two transactions carry AxLOCK = 1 and the responses carry the exclusive codes:

exclusive-access — load-exclusive then store-exclusive, success case

7 cycles

Figure 3 — exclusive-access on the wire. The load-exclusive read drives ARLOCK=1 and gets RRESP=EXOKAY (monitor set). The store-exclusive write drives AWLOCK=1; its BRESP is EXOKAY if the monitor was still set (atomic success) or OKAY if an intervening write cleared it (failure). The response code, not the data path, reports the atomic outcome.

4. The Success/Failure Decision and Constraints

The store-exclusive outcome is a single decision — was the monitor still set?

Figure 4 — the store-exclusive decision. If no other agent wrote the location since the load-exclusive (monitor still set), the write commits and returns EXOKAY (atomic success). If an intervening write cleared the monitor, the write is suppressed and returns OKAY — software must treat OKAY as failure and retry the entire load-exclusive/modify/store-exclusive sequence.

Exclusive access has constraints so monitors can be implemented simply: the exclusive read and write must use the same address, size, and length (they're a matched pair); the number of bytes must be a power of two and the address aligned to that size; the total must be ≤128 bytes (a single burst); and the pair typically uses the same AxID. Violating these makes the behavior unpredictable. AXI3 also had a locked access mode (hard bus locking), which AXI4 removed — exclusive access is the surviving atomicity mechanism (Chapter 9.4).

5. Common Misconceptions

Myths to unlearn

"OKAY from a store-exclusive means success." The opposite — on a store-exclusive, EXOKAY = success, OKAY = failure (the monitor was cleared; the write didn't happen). Software must retry on OKAY.
"The exclusive write always updates memory." Only if the monitor is still set. A failed store-exclusive does not write — that's the whole point of atomicity.
"Exclusive access locks the bus." No — it's monitor-based, non-blocking. Bus-locking was the separate AXI3 locked mode, removed in AXI4.
"Any location supports exclusive access." Only locations with a monitor (local at a slave, or global in the interconnect). An exclusive read to an unmonitored region returns OKAY, signalling exclusivity isn't supported — software must check.
"The exclusive read and write can differ in size/address." They must be a matched pair — same address, size, length, aligned, power-of-two bytes, ≤128 bytes — or behavior is unpredictable.
"EXOKAY can appear on a normal access." No — EXOKAY only ever results from an exclusive access (AxLOCK=1).

6. Debugging Insight

🔍 Debugging insight — atomicity failures map to monitor and response handling

Exclusive-access bugs cluster around the monitor and the response semantics:

A lock/atomic sequence never succeeds (always retries)? Either the monitor keeps getting cleared (real contention — expected, software should eventually win) or there's no monitor for the region, so the store-exclusive always returns OKAY. Check whether the region has a local/global monitor and whether the exclusive read returned EXOKAY (monitoring) vs OKAY (unsupported).
An atomic update is silently non-atomic (lost updates)? Software likely ignored the OKAY-means-failure response and proceeded as if the store-exclusive succeeded. Verify the code branches on EXOKAY vs OKAY and retries on OKAY.
Exclusive works for one master but not across masters? Only a global monitor (in the interconnect) provides cross-master atomicity; a local monitor at one slave won't catch another master's write. Check that the shared location is covered by a global monitor.
Unpredictable exclusive behavior? A constraint violation — mismatched address/size/length between the read and write, misalignment, non-power-of-two bytes, or >128 bytes. Validate the pair against the rules.

Triage: always-fails → missing monitor (or genuine contention); lost atomicity → ignoring the OKAY failure code; cross-master failure → need a global monitor; erratic → constraint violation. The single most common software bug is treating OKAY as success.

7. Verification Insight

✅ Verification insight — both outcomes, the monitor, and cross-master atomicity

Exclusive access must be verified for both outcomes and the constraints. Drive the success path (load-exclusive → no intervening write → store-exclusive returns EXOKAY, memory updated) and, critically, the failure path: inject an intervening write between the exclusive read and write and assert the store-exclusive returns OKAY and does not modify memory — the atomicity guarantee. Check the monitor state machine directly: monitor set on exclusive read (EXOKAY returned), cleared by an intervening write, and the correct response on the subsequent store-exclusive. Verify unsupported regions return OKAY to an exclusive read, and that cross-master atomicity works through a global monitor (one master's intervening write correctly fails another master's store-exclusive).

Coverage should include: success and failure (intervening-write) sequences; the intervening write coming from the same vs a different master; back-to-back and contended exclusive sequences (multiple masters racing on one location, asserting at most one store-exclusive succeeds per round); unsupported-region exclusive reads; and constraint edges (max 128-byte, alignment, matched read/write pair). The highest-value test is the contention race — multiple masters attempting exclusive updates to the same location — proving exactly one wins (EXOKAY) and the rest fail (OKAY) and retry, with memory reflecting a single atomic update. This is the core atomicity correctness property.

8. Interview Questions

9. Summary

Exclusive access is AXI's hardware atomic read-modify-write — load-exclusive / store-exclusive, the protocol's LDREX/STREX. A load-exclusive (ARLOCK=1) sets an exclusive monitor and returns EXOKAY; after the modify, a store-exclusive (AWLOCK=1) to the same matched location returns EXOKAY and commits if no other agent wrote the location in between (atomic success), or OKAY and does not write if an intervening write cleared the monitor (failure → software retries). The famous inversion: on a store-exclusive, EXOKAY is success and OKAY is failure. Monitors are local (within a subordinate) or global (in the interconnect, for cross-master atomicity), and the access pair is constrained (same address/size/length, aligned, power-of-two, ≤128 bytes) so monitors stay simple.

The discipline: software must check the response and retry on OKAY — treating OKAY as success is the canonical bug that silently breaks atomicity. Exclusive access provides lock-free synchronization without bus locking, which is why AXI4 removed the heavyweight locked mode entirely. Verify both outcomes (especially the intervening-write failure that must not modify memory) and the cross-master contention race (exactly one winner). Next: that removed locked access mode — what AXI3 had, why it existed, and why AXI4 dropped it in favor of exclusive access.

10. What Comes Next

You've got the atomic mechanism; next, the legacy mode it replaced:

9.4 — Locked Access (Legacy AXI3) (coming next) — what AXI3's locked access did, why it locked the bus, and why AXI4 removed it.

Previous: 9.2 — Read/Write Independence. Related: 6.4 — AxLOCK & AxCACHE for the AxLOCK encoding, and 6.8 — RESP & LAST Signals for the EXOKAY response code. For the broader protocol catalog, see the AMBA family overview doc.