是一个没有延迟的无限循环不良练习吗？

Question

简而言之: 与延迟减慢的类似循环相比,未延迟的while循环是否会消耗大量的处理能力？

在不那么短的时间内:

我经常遇到这个问题.我正在编写程序的核心部分(微控制器单元或计算机应用程序),它包含一个半无限的while循环,以保持活跃并查找事件.

我将采用这个例子:我有一个使用SDL窗口和控制台的小应用程序.在while循环中,我想监听此SDL窗口的事件,但我还想根据命令行输入通过全局变量来中断此循环.可能的解决方案(伪代码):

// Global
bool running = true;

// ...

while (running)
{
    if (getEvent() == quit)
    {
        running = false;
    }
}

shutdown();

核心while循环将从已侦听的事件或外部事件中退出.但是,这个循环是连续运行的,甚至可能是每秒1000次.这有点过分杀人,我不需要那个响应时间.因此,我经常添加一个延迟声明:

while (running)
{
    if (getEvent() == quit)
    {
        running = false;
    }
    delay(50); // Wait 50 milliseconds
}

这将刷新率限制为每秒20次,这很充足.

所以.这两者之间有真正的区别吗？这很重要吗？在微控制器单元上是否会更加重要(处理能力非常有限(除了程序之外没有别的东西需要运行......))？

Answer 1

好吧，事实上这不是一个关于 C++ 的问题，而是答案取决于 CPU 架构/主机操作系统/delay() 实现。

如果它是一个多任务环境，那么delay()可以（并且可能会）帮助操作系统调度程序更有效地完成其工作。然而，真正的区别可能太小而难以注意到（除了旧的协作多任务处理，其中必须使用delay()）。
如果它是单任务环境（可能是某些微控制器），那么如果底层实现能够执行一些专用的低功耗指令而不是普通循环，那么delay()仍然有用。但是，当然，除非您的手册明确说明，否则不能保证它会发生。

考虑到性能问题，很明显，您可以接收和处理一个具有显着延迟的事件（甚至完全错过它），但如果您认为这不是一种情况，那么对于delay() 来说没有其他缺点。

是一个没有延迟的无限循环不良练​​习吗？