Atomic compare‑exchange stalls when a timeout is enforced on AArch64

Answer

An LL/SC (LDXR/STXR) loop can spin forever when another core repeatedly wins the store‑exclusive, causing the loop to retry without observing unrelated stores such as a cancellation flag. This livelock is possible because the LL/SC model does not guarantee forward progress; only executing a WFE/WFI or a separate memory‑ordering instruction provides the architectural guarantee of eventual progress.

When the Large System Extensions (LSE) are available, the compiler emits a single CAS RMW instruction (CASP/CASL). This instruction completes in bounded steps and carries implicit acquire/release semantics, so a concurrently updated cancellation flag becomes visible before the CAS returns, preventing the indefinite stall.

To guarantee that a timeout check is observed even when the code must fall back to an LL/SC retry loop, either:

1. Compile for an LSE‑capable target (‑march=armv8.2‑a or ‑march=armv8‑a+lse), which makes the compiler use the single CAS instruction; or
2. Insert a lightweight forward‑progress mechanism inside the retry loop, e.g., a yield/pause followed by an acquire fence (std::atomic_thread_fence(std::memory_order_acquire) or __builtin_dmb(ish)) after reading the cancellation flag and before the LDXR/STXR pair.

Likely explanation vs. confirmed facts

Confirmed facts (from the ARM Architecture Reference Manual and LSE specification):

• LL/SC does not guarantee forward progress; livelock can persist under contention.
• LSE CAS completes in bounded steps and includes implicit acquire/release ordering.
• Executing WFE/WFI or a separate memory‑ordering instruction breaks livelock.

Likely explanation for the observed hang:

The program’s timeout/cancellation flag is read with the same memory ordering as the atomic compare‑exchange. In a pure LL/SC loop without an intervening fence or yield, the core may repeatedly win the load‑exclusive but lose the store‑exclusive, causing the loop to retry and never re‑load the cancellation flag, so the deadline check appears stale.

Steps to guarantee timeout visibility (apply one)

1. Check the compile flags: if ‑march=armv8.2‑a or ‑march=armv8‑a+lse is present, the code already uses LSE and no further change is needed.
2. If LSE is not enabled, add the following pattern inside the compare_exchange_weak loop:

while (!atomic.compare_exchange_weak(expected, desired)) {
    // read cancellation flag with acquire semantics
    if (cancel_flag.load(std::memory_order_acquire)) break;
    // optional yield to reduce contention
    std::this_thread::yield();
    // explicit acquire fence before next LDXR
    std::atomic_thread_fence(std::memory_order_acquire);
}

This ensures that each iteration observes any update to the cancellation flag before attempting another LDXR/STXR pair.
Missing diagnostic detail
To confirm which path the binary is taking, we need to know: Is the binary built for an LSE‑capable core (‑march=armv8.2‑a or ‑march=armv8‑a+lse)? Knowing this determines whether the fix is simply enabling LSE or whether we must add the yield/fence loop.