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.

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...

[3] https://smackernews.com/item/24489829 HN

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.

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

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.

If contention is expected, would it be better to first perform a relaxed read before the exchange? For example:

  auto lock() noexcept -> void {
      auto backoff = 1;
      do {
          while (locked_.load(std::memory_order_relaxed)) {
              for (auto i = 0; i < backoff; ++i) _mm_pause();
              backoff = backoff < 64 ? backoff << 1 : 64;
          }
      } while (locked_.exchange(true, std::memory_order_acquire);
  }

This would have different answers depending on if it ran on a machine with a more closely-shared cache, right? For example on an Intel efficiency core cluster where 4 cores share an L2.

I think one area where spinlock could be useful is fibers. There you have an option to schedule another fiber instead of spinning CPU until timeslice runs out.