LDAR/STLR Acquire-Release vs DMB barriers for aarch64 producer-consumer ordering
0 reputation · 20 Aug 2022, 21:39 UTC
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?