LDAR/STLR Acquire-Release vs DMB barriers for aarch64 producer-consumer ordering

Question

A design decision is needed for a producer-consumer handoff on aarch64 under the Weakly Ordered memory model. The goal is to guarantee visibility of data writes before the consumer observes the ready flag, without assuming x86-style Total Store Ordering.

Two documented approaches are under consideration. Load-Acquire LDAR and Store-Release STLR provide one-way ordering with lower pipeline impact than a full Data Memory Barrier DMB. Explicit DMB barriers provide stricter ordering at higher cost. A further constraint is portability across ARMv8-A implementations where Large System Extensions are optional and may be absent.

The unresolved behavior concerns how to reason about correctness and performance when the presence of LSE atomics cannot be assumed at build time and Acquire-Release semantics must be combined with weakly ordered accesses.

Which primitive choice preserves required ordering for the handoff while minimizing unnecessary barriers on weakly ordered cores? How should the design handle implementations where LSE is unavailable versus implementations where it is present? Is there a documented way to reason about one-way Acquire-Release ordering versus full barriers for this specific pattern?

Tasadduq Burney · Answer

Choosing the primitive
On ARMv8‑A the producer writes data, then stores a flag with STLR (store‑release). The consumer loads the flag with LDAR (load‑acquire) and then reads the data. This one‑way acquire‑release pattern guarantees that the consumer sees all data writes performed before the STLR, without the pipeline cost of a full DMB ISH barrier.
LSE availability: Base ARMv8.0‑A already provides LDAR and STLR for 32/64‑bit registers. Large System Extensions (LSE, ARMv8.1‑A) add atomic read‑modify‑write instructions (CAS, SWP) but do not change the semantics of plain LDAR/STLR. If LSE is absent, the same acquire‑release ordering holds; only atomic CAS/SWP are unavailable.
Compiler reordering: C11/C++11 memory_order_acquire/release map to LDAR/STLR on aarch64, but the compiler may still reorder ordinary loads/stores around the atomic unless a explicit fence or compiler barrier is used. Wrap the flag access with std::atomic_thread_fence or GCC/Clang __atomic_signal_fence to prevent unwanted reordering.
Domain considerations: LDAR/STLR assume the flag and data reside in the inner‑shareable (ISH) domain. On big.LITTLE or heterogeneous systems where cores differ in outer‑shareable (OSH) layout, a DMB SY may be required, or the flag must be placed in shared memory that is ISH.
Performance impact: LDAR/STLR compile to single instructions with 1‑3 cycle latency on modern cores (Cortex‑A72, A76, Neoverse‑N1). A DMB ISH serialises the load/store pipeline and typically costs 10‑30 cycles. For a simple handoff the acquire/release pair is therefore 2‑5× cheaper.
If you can confirm whether the flag is placed in the inner‑shareable domain (ISH), the recommendation may shift; otherwise the acquire/release pattern is sufficient.

LDAR/STLR Acquire-Release vs DMB barriers for aarch64 producer-consumer ordering

1 answer

Choosing the primitive

Your perspective belongs here.

0 question comments