ab (a.delete@this.b.com) on January 5, 2020 4:15 am wrote:
> > If everyone reads that book prior to posting/writing a blog about multi-threading
> > or locking, there would be much less misinformation/confusion.
>
> > The title for chapter 7 is "Spin Locks and Contention" and discusses various issues that Linus
> > has outlined, including dangers of pure spin locks, fairness, designing NUMA aware locks, etc.

Can we state our points simply instead of asking people to read books? No one does that. Books go out of date in five years. Books cost money too (just like journal articles behind a paywall - effectively useless)

> Just reading the Linux manpages would have been a good start:
>
> http://man7.org/linux/man-pages/man3/pthread_spin_init.3.html#NOTES
>
>

Spin locks should be employed in conjunction with real-time
> scheduling policies (SCHED_FIFO, or possibly SCHED_RR). Use of spin
> locks with nondeterministic scheduling policies such as SCHED_OTHER
> probably indicates a design mistake. The problem is that if a thread
> operating under such a policy is scheduled off the CPU while it holds
> a spin lock, then other threads will waste time spinning on the lock
> until the lock holder is once more rescheduled and releases the lock.
>
> If threads create a deadlock situation while employing spin locks,
> those threads will spin forever consuming CPU time.
>
> User-space spin locks are not applicable as a general locking
> solution. They are, by definition, prone to priority inversion and
> unbounded spin times. A programmer using spin locks must be
> exceptionally careful not only in the code, but also in terms of
> system configuration, thread placement, and priority assignment.

I think someone who spent months dealing with and studying a problem fully understands the basic disadvantages of spinlocks as outlined above. Also, I respect the original author for running tests and collecting hard data.

So I'm wondering why spinlocks were used in the first place (not necessarily by the author - tons of games use it apparently). My thought is frequency scaling. If your thread blocks on a lock (or IO, or whatever), the kernel will de-schedule it. If there's nothing else to dispatch on that core, it'll be allowed to idle and clock down to reduce power consumption. When the thread acquires the lock and gets woken up, the CPU core has to clock back up and can't do that instantly.

See anandtech's article about skylake speed shift. Skylake takes ~35ms to clock all the way up from a power efficient low frequency state. Haswell took over 100 ms to do the same. One frame at 60 fps is 16.7ms, so that's a lot of time.

If your thread finishes processing in 10 ms and blocks for 6.7 ms before it's woken back up, you could end up losing performance because your average CPU clock is 2 GHz instead of 4 GHz. But if you spin for those 6.7 ms, the core stays at 4 GHz.

And sure, the user can configure the OS to keep cores at top clocks even when no work's available to dispatch. But that's also a pretty bad solution because it'd seriously hurt battery life.