multithreading - 为什么自旋锁在单个 CPU 上没有意义？

Question

在阅读操作系统三篇文章时，我发现了以下句子:

"To work correctly on a single processor, it requires a preemptive scheduler (i.e., one that will interrupt a thread via a timer, in order to run a different thread, from time to time). Without preemption, spin locks don’t make much sense on a single CPU, as a thread spinning on a CPU will never relinquish it."

为什么单CPU支持多线程，单CPU上自旋的线程永远不会放弃？是因为在这种情况下自旋锁只是浪费了太多的 CPU 资源吗？ CPU 内核的数量如何影响互斥锁和自旋锁等不同锁的性能？

Answer 1

在单个 CPU 上，单核 CPU 你仍然可以拥有 thread multi-tasking (多线程)，需要注意的是，由于缺少多个执行单元，通常一次只能执行一个线程。如果没有多个执行单元(硬件多线程)，硬件依赖于内核定义的“software multi-threading”策略——低级操作系统软件来确定执行什么以及何时执行。

Preemption是一种策略，涉及更积极地引导(可以这么说)这些多个执行流沿单个路径通常部分通过使用基于定时器的中断实现。与抢占相反——cooperative scheduling -- 采用更加自由放任的方法，将其留给事件线程来发出完成信号。

因此，协作调度方案允许一个线程进程的线程持有唯一的计算资源(在这种情况下)更长时间:

但是如果这种方案中的事件线程试图永远保持事件状态呢？本质上，这就是这里发生的事情。

自旋锁是主动等待锁定请求的资源。该线程将只是坐在那里等待任何其他线程锁定它想要放弃的资源。由于文本表明硬件情况一次只允许一个事件线程，如果请求的资源被锁定，这意味着它被一个非事件线程锁定。

如果没有抢占，则由线程决定何时停止执行。因此，当事件线程自旋锁时，它将永远坐在那里——这就是所谓的挂起。要阻止这种情况，用户可能会被迫物理关闭系统以清除缓存/动态内存。

抢占式调度线程实现为time slices .当在线程中完成进一步工作之前需要访问特定资源时 spinlock -- 忙碌的等待 -- 是有道理的。

有了抢占，内核会自动force context switch在指定的时间后，即使只有一个 CPU 也不会挂起。最终线程与资源 lock将获得一些时间并释放其资源。当自旋锁线程获得下一个预定时间时，它将能够锁定资源并继续。

总体而言，这意味着更少的挂起。

但是，自旋锁仍然会遇到更复杂的抢占式调度问题，例如死锁......当两个线程各自被自旋锁同时持有彼此的资源时:

但是，这种情况通常可以通过内核对资源锁定请求的保护来避免。

在一个完美的世界中，协作调度与精心设计的线程可能会导致关键进程的执行速度更快一些。因此，这是 Mac OS 和 Windows 3.x 等精简的旧操作系统中的常见方法。但是，随着计算需求的增加，避免协作调度的缺点变得越来越困难，因此几乎所有现代操作系统内核都使用抢占式调度程序。