Optimizing a Spin-Lock

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.

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.

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

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.

[dead]