“忙等待”与“睡眠”的权衡是什么？

这是我之前问题的延伸

unix/linux 套接字中的阻塞模式如何工作？ https://stackoverflow.com/questions/1107391/how-does-blocking-mode-in-unix-linux-sockets-works

我现在从互联网上收集到的信息是，所有调用阻塞调用的进程都会进入睡眠状态，直到调度程序找到解除阻塞的原因。原因可能多种多样，从缓冲区空到缓冲区满，再到任何其他情况。

但是，这是否是一种有效的实时方式，比如说硬实时应用程序？因为当解除阻塞条件成立时，进程不会解除阻塞，而是当调度程序给他他的 CPU 切片，并且解除阻塞条件都成立时，进程不会解除阻塞。

就好像你想要一个响应式解决方案一样，我不认为“自旋锁”或“忙等待”是正确的方法，CPU 切片被浪费了，总体而言系统将变得无响应或可能很差 -反应灵敏。

有人可以澄清这些相互矛盾的想法吗？

睡觉直到调度程序叫醒你是正常/首选的事情。

旋转（不睡觉的另一种等待方式）不太常见，具有以下效果：

• 保持 CPU 繁忙，并防止其他线程使用 CPU（直到/除非旋转线程完成其时间片并被抢占）

• 可以在您等待的事情发生的那一刻停止旋转（因为您不断检查该事件，并且您不需要花费时间来唤醒，因为您已经醒了）

• 不调用进入睡眠和再次唤醒所需的 CPU 指令

如果延迟的长度为very短（例如，如果延迟仅为执行 100 个 CPU 指令所需的时间）。