A spin-lock that never sleeps gets 5.7x faster and uses 5.4x less energy
Optimizing a Spin-Lock
Starting from a naive atomic exchange loop, the author walks through four versions of a spin-lock, each fixing a specific bottleneck: relaxed memory ordering, test-and-test-and-set with a read-only spin, and exponential backoff. At four threads, latency drops from 246 ns to 43 ns and energy from 64.92 J to 11.92 J. The post includes benchmarks, perf counters, and the full C++ code.
In most code, std::mutex is still the right default. Consider a spin-lock when the threads are pinned to dedicated cores, and only after measuring.
- pizlonator
Super dangerous to benchmark lock performance using microbenchmarks. If you have a tiny benchmark, then you're putting the CPU and memory into a very specific and unusual state (everything is quiet other than the lock itself).
The real world story for locks is usually that you're not rage-contending 100% of the time, but that you have some contention combined with CPUs doing some real work and some real memory accesses.
What I've found is that in those more real scenarios, the locks that perform best in microbenchmarks fall apart compared to completely different and unexpected algorithms.
- vova_hn2
I want to share an excellent related article, "A Concurrency Cost Hierarchy" [0] by Travis Downs [1]. It was posted to HN many times [2], the largest discussion has 26 comments [3].
My own programming experience is mostly Python, so throughout the most of my career I treated locks as pure magic and didn't think much about what happens under the hood.
At some point in my life I became interested in Rust and lower-level programming and this article in particular really helped me to set my head straight on this topic. It doesn't only explain how concurrency primitives actually work, but it also explains why they work this way, what choices and trade-offs are involved.
This article uses C++ for all examples, but there are really nothing language specific, all principles will work in Rust, C, Zig etc
[0] https://travisdowns.github.io/blog/2020/07/06/concurrency-co...
[1] https://travisdowns.github.io/
[2] https://hn.algolia.com/?q=https%3A%2F%2Ftravisdowns.github.i...
- tombert
I genuinely had not heard of anyone actually using a spinlock in production code until I started using LMAX Disruptor a few years ago.
I was always told that they were an anti-pattern, and I think that generally that is a pretty good rule of thumb, but I guess like most stuff in CS: there are always exceptions to "good rules of thumb".
I still haven't actually explicitly written a spinlock for anything in production, but Disruptor has shown me that there are cases for it.
- dalvrosa
Thanks for sharing! Happy to get feedback :)
Note that I don't recommend spinlock for most cases, only when there is a 1:1 mapping between threads and phsycal CPU cores, and only after measuring
- RossBencina
TFA mentions power usage from a dollar cost perspective, but there is also the thermal aspect. You do not want to trigger thermal throttling (or lose boost) while doing almost nothing.