https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126235
Bug ID: 126235
Summary: std::atomic<std::shared_ptr<T>> can stall under
SCHED_FIFO on a single CPU
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wolfgang.hoffmann at besi dot com
Target Milestone: ---
Created attachment 65024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65024&action=edit
c++ reproducer of the stall
On Linux x86_64, std::atomic<std::shared_ptr<T>> can stall indefinitely under
concurrent read/write access when the participating threads run with SCHED_FIFO
on a single CPU core.
I can reproduce this reliably on Ubuntu 24.04 (gcc/libstdc++ 13.3.0) and Ubuntu
26.04 (gcc/libstdc++ 15.2.0) with the attached code that runs:
- a low-prio getter thread that continuously loads the atomic shared pointer
- a mid-prio setter thread that continuously stores alternating values to the
atomic shared pointer and sleeps a bit between stores
- a high-prio watchdog thread that supervises the setter in batches and aborts
if a batch does not complete within a timeout
The stall occurs in std::atomic<std::shared_ptr<T>>::load() / store()
internals. It seems like the getter is preempted by the setter while holding an
internal lock, and the setter not yielding to the getter while waiting for the
lock.
The stall does not occur when running on a multi core CPU with the CPU affinity
restrictions removed.
For comparison, the same reproducer works as expected when using the deprecated
std::atomic_load / std::atomic_store free functions on std::shared_ptr<T>
instead.
