问Linux中断与轮询

EN

我会创建一个设备，并在read上使用userland程序块。不需要等待10毫秒之间，这是有效地处理阻塞。

在使用poll的意义上进行轮询(是的，我理解这不是您的意思)会很好，但是没有理由调用两个函数(首先是poll，然后是read)，因为一个函数无论如何都可以这样做。不需要每隔10 to就做一次，您可以在处理完上次读取的内容后立即再次调用poll。

在每10 is检查一次已知内存位置的意义上，轮询是不可取的。这不仅是一次丑陋的黑客攻击，比您想象的还要复杂(您将不得不将包含该内存位置的页面映射到用户空间)，以及一种不必要地消耗CPU的忙碌等待形式，它的平均延迟为5ms，最坏的延迟为10 5ms，这是完全不必要的。read的平均和最坏的延迟大约为零(嗯，不完全，但几乎是零)。它就像唤醒一个被阻塞的任务一样快)。

中断(即信号)非常有效，但与简单的读取和阻塞相比，使程序变得更加复杂/扭曲(必须编写信号处理程序，在处理程序中可能不使用某些功能，必须与主应用程序通信，等等)。虽然从技术上讲，这是一个很好的解决方案，但我建议不要这样做，因为程序不需要过于复杂。

投票没有等待的优势。这个过程仍然需要计划和切换到所有这些，然后它会做一些无用的投票。

Linux在中断返回时运行调度程序，因此当您在内核内中断处理程序中唤醒等待任务时，它具有高优先级集(很明显，您应该给予它实时优先级)，任务将立即被调度。你不能用投票来打败它。

(字符)设备文件的标准接口相当快，所以只需实现阻塞读取、轮询(这是阻塞的系统调用，而不是真正的轮询)和可能的异步读取(使用实时信号)，但我怀疑在读取系统调用中等待的专用线程的性能将优于AIO。而且写起来也更容易。您应该在内核源代码中找到足够的示例。

您似乎没有提到任何困难的时间限制，所以您确实可以采用这两种方法。但是，正如Martin所说，轮询会给应用程序带来一些开销，这可能是您不想要的。

就我个人而言，我会使用内核触发的中断或事件标志。虽然您可能没有严格的时间限制，但我认为您需要的是更具确定性的东西，而不是不具有确定性的东西。内核中断会让你更接近这个目标。