8 ms·
Once you use atomic cmpxchg you've lost a great deal of scalability because it implies a retry loop (internal or by the user) The last thing you want is all of
by nly 2mo ago
Once you use atomic cmpxchg you've lost a great deal of scalability because it implies a retry loop (internal or by the user)
The last thing you want is all of the threads failing to cmpxchg (spuriously or otherwise ) spinning on a shared cacheline
Real world alternatives show atomic xchg only solutions scale to hundreds of threads.
- adzm 2mo ago> Real world alternatives show atomic xchg only solutions scale to hundreds of threads But notably only with certain workloads
- nly 2mo agoOnce you get to using custom lock free queues you should be picking something that matches your workload/broader design anyway.
- RossBencina 2mo agoAgreed. But you make it sound like the worst case is necessarily fatal. It depends on the use-case. The workable cmpxchg algorithms will make progress on at least one core each round. In a push or pop operation one of the cmpxchg must have succeeded for another to fail. The atomic xchg algorithms that I know of have other undesirable pathologies (e.g. a suspended producer can stall the consumer).
- nly 2mo agocmpxchg can fail spuriously on some platforms