“忙碌的等待”和“睡眠”的权衡是什么？
这是我上一个问题的延伸
How does blocking mode in unix/linux sockets works?
我现在从Internet收集到的所有调用阻塞调用的进程都处于休眠状态，直到调度程序找到解除阻塞的原因。原因可能不同，从缓冲区为空到缓冲区已满，再到任何其他情况。
但是，这是否是一种有效的实时方式，比如说硬/硬实时应用？因为当解除阻塞条件为真时，而不是当调度器将他的CPU片给他时，进程不被解除阻塞，并且解除阻塞条件都为真。
如果你想要一个响应式的解决方案，我不认为“自旋锁”或“繁忙等待”是正确的方式，CPU片被浪费了，而且总的来说，系统将变得不响应或响应不佳。
有没有人能把这些矛盾的想法。
回答 5
Stack Overflow用户
发布于 2009-07-10 04:49:39
一直睡到调度器把你叫醒是正常的/首选的做法。
旋转(等待的另一种方式，不睡觉)不太常见，具有以下效果：
- 使CPU保持繁忙，并阻止其他线程使用CPU (直到/除非旋转的线程完成其时间片并被预置)
- 可以在您等待的事件发生的那一刻停止旋转(因为您正在不断地检查该事件，并且您不需要花费唤醒它的时间，因为您已经处于唤醒状态)
- 不会调用进入睡眠和再次唤醒所需的CPU指令
如果延迟的长度非常短(例如，如果延迟仅为执行100条CPU指令所需的时间)，则旋转可能比进入睡眠更有效(总CPU更少)。
Stack Overflow用户
发布于 2011-01-08 09:40:41
如果在您的应用程序的用例中，上下文切换将比占用几个CPU周期更昂贵，因为可以保证在短时间内满足您的条件，那么忙碌的等待可能对您有好处。
否则，您可以通过休眠或cond_wait()ing强制放弃CPU。
对于强制上下文切换，我能想到的另一个场景如下：
while(condition)
sleep(0);Stack Overflow用户
发布于 2009-07-10 03:56:37
首先，您有一个误解：
阻塞调用不是“忙碌等待”或“自旋锁”。阻塞调用是可休眠的--这意味着CPU将在其他任务上工作，不会浪费cpu。
关于阻止调用的问题的
阻塞调用更容易--它们更容易理解，更容易开发，更容易调试。
但它们是大量的资源。如果您不使用线程，它将阻塞其他客户端；如果您使用线程，则每个线程将占用内存和其他系统资源。即使你有足够的内存，切换线程也会使缓存变冷并降低性能。
这是一种权衡--更快的开发和可维护性？或者可扩展性。
https://stackoverflow.com/questions/1107593
复制相似问题
腾讯云开发者
