Locked Transfers (HLOCK)

Chapters 10.1–10.3 covered how the arbiter grants the bus and signals the current master. This chapter covers a master's ability to prevent the arbiter from changing ownership mid-sequence: locked transfers, via HLOCK. A master asserts HLOCK to tell the arbiter "don't change bus ownership during my sequence." While HLOCK is asserted, the arbiter keeps granting that master and masks other masters' grants — so no other master can take the bus mid-sequence. This makes the locked sequence atomic on the bus: it runs uninterrupted, with no other master interleaving a transfer. The purpose is atomic read-modify-write operations — like a semaphore acquire (read a lock variable, modify it, write it back) — which must complete with no other master accessing the location in between. HLOCK provides bus-level atomicity, which is how multi-master systems implement synchronization primitives. When the master deasserts HLOCK, normal arbitration resumes.

1. What Is It?

A locked transfer (or locked sequence) is a sequence of transfers during which a master asserts HLOCK to tell the arbiter not to change bus ownership — keeping the master granted throughout, so the sequence runs atomically.

• The master asserts HLOCK at the start of the sequence (a master output to the arbiter).
• While HLOCK is asserted, the arbiter keeps granting that master and masks other masters' grants — no other master can take the bus.
• The master deasserts HLOCK at the end, and normal arbitration resumes.

So HLOCK gives a master atomic access across multiple transfers: the arbiter won't hand the bus to anyone else while HLOCK is asserted, so the master's sequence completes uninterrupted. This is stronger than just owning the bus for one transfer (which normal granting provides) — HLOCK guarantees ownership across several transfers, preventing any interleaving. The master controls the lock: assert HLOCK to lock, deassert to unlock. While locked, the master is the sole owner; while unlocked, normal arbitration applies. So a locked transfer is a master-controlled atomic window on the bus.

2. Why Does It Exist?

Locked transfers exist because some operations must be atomic across multiple bus transfers — most importantly read-modify-write for synchronization — and normal arbitration (which can hand the bus to another master between transfers) would let another master interleave, breaking the atomicity.

The canonical case is a read-modify-write (RMW) — for example, acquiring a semaphore: read the lock variable, check it's free, write it to "taken." This must be atomic: no other master may access the lock variable between the read and the write.

Without locking, here's the race: master A reads the semaphore (sees it free), but before A writes it "taken," the arbiter hands the bus to master B, which also reads the semaphore (also sees it free) — so both write "taken" and both think they own it. The atomicity is broken because B intervened between A's read and write. HLOCK prevents this: master A asserts HLOCK across its read and write, so B cannot access the semaphore until A finishes — A reads, modifies, writes, all uninterrupted, then unlocks. Now B reads "taken" (correctly seeing A acquired it). So locked transfers exist to make RMW atomic, which is essential for correct synchronization (semaphores, mutexes, spinlocks) in a multi-master system. Without atomicity, synchronization primitives would have races.

The reason this requires arbiter cooperation (HLOCK, not just the master holding the bus) is that only the arbiter can prevent another master from being granted. A master can drive the bus when granted, but it can't, by itself, stop the arbiter from granting someone else between its transfers. So the master needs to tell the arbiter to keep it granted — which is what HLOCK does. So HLOCK exists as the master-to-arbiter signal for "don't change ownership"; the arbiter then masks other grants. So locked transfers are a cooperative mechanism: the master requests the lock (HLOCK), the arbiter enforces it (masking others). This is why HLOCK is part of the arbitration protocol — atomicity across transfers requires the arbiter's participation.

The reason locks must be bounded (the master must release HLOCK) is fairness: while one master holds the lock, all others are blocked (they can't get the bus). So a master must hold the lock only as long as needed (a short RMW) and release it promptly. A master that held HLOCK indefinitely would starve all others (and effectively hang the bus for them). So locked transfers exist with the expectation that they're short and bounded — atomic windows, not indefinite ownership. This is the cost of atomicity: while locked, others wait, so locks must be brief. So the mechanism exists for short atomic sequences, with the master responsible for releasing the lock promptly. (A protocol checker would flag an excessively long lock.)

3. Mental Model

Model HLOCK as putting a "do not disturb — in progress" sign on a shared workbench while you do a multi-step task — no one else can use the bench until you take the sign down, so your steps complete without interference.

A shared workbench (the bus) is normally available to whoever the supervisor (arbiter) assigns it to. But sometimes you have a multi-step task that must be done without interruption — like measuring a part, adjusting it, and re-measuring (a read-modify-write), where someone else touching the part mid-task would ruin it. So you put up a "do not disturb — in progress" sign (assert HLOCK): the supervisor sees it and won't assign the bench to anyone else until you take the sign down. You do your steps uninterrupted (the locked sequence), then take down the sign (deassert HLOCK), and the bench is available again. While your sign is up, others wait — so you keep your task short and take the sign down promptly, or you'd hold up everyone. The sign guarantees your multi-step task completes atomically, with no one interfering.

This captures HLOCK: the "do not disturb" sign = HLOCK; the supervisor not reassigning the bench = the arbiter not changing ownership (masking others); your uninterrupted multi-step task = the atomic locked sequence; taking down the sign = deasserting HLOCK; keeping it short = bounded locks (don't starve others). The sign reserves the shared resource for your atomic task.

Watch a locked sequence hold off arbitration:

The model's lesson: HLOCK is the "do not disturb" sign — the arbiter holds off others until the locked sequence completes. In the waveform, the other master requests throughout but isn't granted until HLOCK deasserts — the locked RMW ran atomically. The lock reserved the bus for the master's multi-step atomic task.

4. Real Hardware Perspective

In hardware, HLOCK is a master output to the arbiter, and the arbiter responds by masking other masters' grants while HLOCK is asserted — keeping the locking master granted across its sequence.

The master asserts HLOCK as part of issuing a locked sequence: it drives HLOCK high at the start (with the first transfer of the sequence) and keeps it high through the sequence, deasserting it at the end. So HLOCK is a master output, asserted across the locked transfers. The master typically asserts HLOCK in conjunction with its bus request — telling the arbiter "I want the bus, and lock it for me." (There's also a related signal HMASTLOCK, the registered/data-phase version of the lock indication that the fabric sees, analogous to how HMASTER works — the master drives HLOCK to the arbiter, and the arbiter/fabric see HMASTLOCK aligned with the transfers.)

The arbiter masks others in response: while HLOCK (for the granted master) is asserted, the arbiter does not grant any other master — it keeps the lock-holding master granted and ignores others' requests (masks them). So the arbiter's logic includes: if the current master has HLOCK asserted, keep granting it and don't switch. This is how the arbiter enforces the lock — by not changing the grant. So in hardware, the lock is enforced by the arbiter's grant logic: HLOCK asserted → hold the grant. The other masters' HBUSREQs stay asserted (they still want the bus) but aren't granted until HLOCK deasserts.

The HMASTLOCK signal is the fabric-visible lock indication (analogous to HMASTER): while HLOCK locks the arbitration, HMASTLOCK (driven aligned with the transfers, like the other address-phase signals) tells the fabric/slaves that the current transfer is part of a locked sequence. A slave may use HMASTLOCK to know the access is locked (e.g., for certain slave behaviors). So there are two related signals: HLOCK (master → arbiter, "lock the arbitration") and HMASTLOCK (the fabric-visible "this transfer is locked"), the latter being essentially the registered/transfer-aligned version. So in hardware, the master's HLOCK controls the arbiter, and HMASTLOCK informs the fabric — paralleling the HGRANT/HMASTER split.

A hardware note on atomicity scope: HLOCK locks the bus arbitration — it guarantees no other master interleaves a transfer on the bus. This provides atomicity at the bus level. For a true atomic RMW, the slave (memory) must also not have the location modified by another path between the read and write — but on a single shared bus where all access goes through the bus, locking the bus suffices (no other master can reach the location). So HLOCK's bus-level atomicity is sufficient when all access to the locked location goes through the locked bus. (In more complex systems with multiple paths to memory, additional mechanisms — like AXI's exclusive accesses — handle atomicity differently.) So in hardware, HLOCK provides bus-level atomicity, sufficient for synchronization on a shared bus.

5. System Architecture Perspective

At the system level, locked transfers are the mechanism for multi-master synchronization — implementing atomic operations (semaphores, mutexes, spinlocks) that coordinate the masters — and their use must be disciplined (short locks) to avoid blocking other masters.

The synchronization role is the key system function: in a multi-master system, the masters (CPUs, DMA engines) often need to coordinate — sharing data structures, signaling each other, ensuring mutual exclusion. This requires atomic operations: a semaphore to guard a shared resource, a mutex for mutual exclusion, an atomic counter. These are built on atomic read-modify-write, which HLOCK enables. So locked transfers are the bus-level foundation for the system's synchronization primitives. Software's locks and semaphores ultimately rely on atomic RMW, which (on a shared AHB) HLOCK provides. So HLOCK underpins multi-master coordination — without it, the masters couldn't reliably synchronize.

The discipline requirement is a system concern: a locked sequence blocks all other masters (they can't get the bus while HLOCK is asserted). So locks must be short and bounded — just the brief atomic operation (a read and a write), not a long sequence. A master holding the lock too long starves others, hurting system responsiveness (and a buggy master that never releases the lock would hang the bus for everyone). So the system discipline is to lock only for the minimal atomic operation and release promptly. This is why atomic operations are designed to be short (a single RMW). So at the system level, locked transfers must be used sparingly and briefly — they're a powerful but blocking mechanism, used only for the essential atomic windows.

The evolution toward other mechanisms is worth noting: HLOCK's approach (lock the whole bus for atomicity) is simple but coarse — it blocks everyone during the lock. More advanced protocols use finer mechanisms: AXI exclusive accesses (exclusive read/write monitored by the slave, succeeding only if no intervening write — no bus locking needed), which allow atomicity without blocking other masters. So the trend is from coarse bus-locking (HLOCK) to fine exclusive-access monitoring (AXI), which is more scalable (doesn't block the whole bus). So HLOCK is the AHB approach to atomicity — simple, bus-level, blocking — while modern high-concurrency systems use AXI's non-blocking exclusives. Understanding HLOCK is understanding the classic shared-bus atomicity mechanism; modern systems often use the finer-grained alternative. So locked transfers are AHB's synchronization foundation, with the discipline of short locks, evolving toward non-blocking exclusives in later protocols.

6. Engineering Tradeoffs

Locked transfers embody the bus-lock-for-atomicity design.

• Lock the bus (HLOCK) vs no atomicity. HLOCK provides atomic RMW (essential for synchronization) at the cost of blocking other masters during the lock. Without it, RMW would race. The atomicity is necessary; the blocking is the cost, mitigated by short locks.
• Coarse bus-lock vs fine exclusive-access. Locking the whole bus (HLOCK) is simple but blocks everyone; AXI's exclusive accesses provide atomicity without bus-locking (finer, non-blocking) at the cost of more complexity (slave-side monitoring). AHB uses the simple coarse lock; AXI the fine non-blocking one.
• Master requests lock, arbiter enforces. Making the lock cooperative (master asserts HLOCK, arbiter masks others) cleanly divides the responsibility — the master knows it needs atomicity, the arbiter enforces it. The master alone couldn't prevent other grants.
• Bounded locks (discipline) vs unbounded. Requiring short, bounded locks keeps the bus responsive (others wait only briefly) at the cost that the master must release promptly. An unbounded lock would starve others. Discipline (short locks) is essential.

The throughline: a locked transfer is a master asserting HLOCK so the arbiter holds the grant — keeping the locking master as sole owner across its sequence, which runs atomically (no other master interleaves). This enables atomic read-modify-write for synchronization (semaphores, mutexes) — the foundation of multi-master coordination. The cost is blocking other masters during the lock, mitigated by the discipline of short, bounded locks. HLOCK is AHB's coarse, bus-level atomicity mechanism, evolving toward finer non-blocking exclusives (AXI) in modern systems.

7. Industry Example

Trace a locked transfer implementing a semaphore.

A system has two CPUs (masters) that coordinate access to a shared resource using a semaphore.

• The semaphore needs atomic acquire. A semaphore is a lock variable: 0 = free, 1 = taken. To acquire it, a CPU must atomically read it (check if free) and, if free, write it taken — with no other master accessing it in between. This is a read-modify-write that must be atomic.
• CPU A acquires with HLOCK. CPU A wants the resource. It asserts HLOCK and performs the RMW: reads the semaphore (sees 0, free), then writes 1 (taken) — all within the lock. While HLOCK is asserted, the arbiter keeps granting CPU A and masks CPU B, so CPU B cannot access the semaphore during CPU A's RMW. CPU A deasserts HLOCK. The acquire was atomic — CPU A now owns the resource.
• CPU B is held off. During CPU A's locked sequence, CPU B requests the bus (req high) but isn't granted — it waits. When CPU A deasserts HLOCK, the arbiter grants CPU B. CPU B then does its own locked RMW on the semaphore: reads it, sees 1 (taken — CPU A has it), so it doesn't acquire (it spins or blocks). So CPU B correctly sees the semaphore as taken, because CPU A's acquire was atomic.
• The race avoided. Without HLOCK, the race would be: CPU A reads 0, then (before A writes) CPU B reads 0 too, both write 1, both think they own the resource — broken. HLOCK prevents this by making A's RMW atomic — B can't read between A's read and write. So the semaphore works correctly.
• The locks are short. Each CPU holds the lock only for the brief RMW (a read and a write), then releases it. So the bus is blocked only briefly during each acquire — the discipline of short locks keeps the bus responsive. The CPUs don't hold the lock across other work.
• A modern alternative. A modern system might use AXI exclusive accesses instead: each CPU does an exclusive read and exclusive write of the semaphore, with the slave monitoring for intervening writes — providing atomicity without locking the whole bus (so other masters aren't blocked). But on a shared AHB, HLOCK is the mechanism.

The example shows HLOCK enabling an atomic semaphore acquire: CPU A locks the bus for its RMW, CPU B is held off (then correctly sees the semaphore taken), and the race is avoided. The locks are short (just the RMW). This is how multi-master synchronization works on a shared AHB — HLOCK provides the bus-level atomicity that semaphores need.

8. Common Mistakes

9. Interview Insight

Locked transfers are a common interview topic — the atomicity purpose (RMW/semaphores) and the arbiter-cooperation mechanism are the signals.

The answer that lands explains the purpose and mechanism: "A locked transfer is when a master asserts HLOCK to tell the arbiter not to change bus ownership during its sequence. While HLOCK is asserted, the arbiter keeps granting that master and masks the other masters, so no other master can take the bus and interleave a transfer — the locked sequence runs atomically. The purpose is atomic read-modify-write, which is needed for synchronization primitives like semaphores and mutexes. For example, to acquire a semaphore, a master reads the lock variable, checks it's free, and writes it taken — and this must be atomic, with no other master accessing the variable between the read and the write. Without a lock, another master could read the semaphore between the first master's read and write, and both could think they acquired it — a race. HLOCK prevents that by keeping the bus locked across the read-modify-write. It's cooperative: the master asserts HLOCK, the arbiter enforces it by masking others. The discipline is to hold the lock only for the minimal atomic operation, because while locked, all other masters are blocked. Modern systems sometimes use AXI exclusive accesses instead, which provide atomicity without blocking the whole bus." The atomicity purpose (RMW/semaphores), the arbiter-cooperation mechanism, and the short-lock discipline are the senior signals.

10. Practice Challenge

Reason from locked transfers.

1. Define it. Explain what HLOCK does and what the arbiter does in response.
2. The atomicity need. Explain why a read-modify-write needs locking, with the semaphore race.
3. Read the waveform. From Figure 3, explain how the other master is held off during the lock.
4. Cooperation. Explain why locking requires the arbiter, not just the master.
5. Discipline & evolution. Explain why locks must be short and how AXI exclusives improve on HLOCK.

11. Key Takeaways

• A locked transfer: a master asserts HLOCK to tell the arbiter not to change bus ownership during its sequence — the arbiter keeps granting that master and masks others.
• The locked sequence runs atomically — no other master can interleave a transfer — enabling atomic read-modify-write (semaphores, mutexes).
• Without locking, RMW would race — another master could access the location between the read and write (e.g., two masters both acquiring a semaphore).
• Locking is cooperative — the master requests the lock (HLOCK, since it knows it needs atomicity), the arbiter enforces it (masking others, since only it controls grants).
• Locks must be short and bounded — while locked, all other masters are blocked, so hold the lock only for the minimal atomic operation and release promptly.
• HLOCK is AHB's coarse bus-level atomicity (related signal HMASTLOCK is the fabric-visible indication); AXI exclusive accesses provide atomicity without blocking the bus (the modern finer-grained approach).

12. What Comes Next

You now understand locked transfers. The next chapters cover the arbitration policies:

• 10.5 — Fixed-Priority Arbitration (coming next) — fixed-priority scheduling and its fairness trade-off.
• 10.6 — Round-Robin Arbitration (coming soon) — round-robin scheduling and when it's preferred.

To revisit the arbitration signals, see HBUSREQ & HGRANT and HMASTER. For the HMASTLOCK signal, see HMASTER & HMASTLOCK. For AXI's exclusive accesses, see AXI vs AHB vs APB. For the broader protocol map, see the AMBA family overview.