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

Issue: atomic compare‑exchange never returns when a deadline is enforced

In a Linux userspace program compiled for ARMv8‑A, a thread repeatedly executes a C++ std::atomic::compare_exchange_weak inside a loop that also checks a deadline and a cancellation flag. When the operation is contended on a big core, the loop appears to spin forever, even though the deadline has elapsed and the cancellation flag is set.

The architecture offers two atomic models: the baseline LL/SC pair (LDXR/STXR) and the Large System Extensions (LSE) RMW instructions (CAS, LDADD). The compiler switches between them based on -march/-mcpu and the target feature macros. If the target is LSE‑capable, the generated code uses a single RMW instruction; otherwise it emits a retry loop that may never observe the cancellation flag if the loop is not properly interleaved with a memory barrier.

Because the cancellation logic is implemented in user space, it relies on the same memory ordering as the atomic operation. A mismatch can make the timeout check never see the updated flag, leading to a silent hang.

What are the documented conditions under which a LL/SC loop can block indefinitely in the presence of a deadline? How does LSE affect the visibility of a cancellation flag in a timeout loop? What compiler or runtime flags can guarantee that a timeout check will be observed even when the atomic operation uses a retry loop?