除了中断驱动架构之外，还有其他型号吗？

Question

我正在阅读有关OS如何使用中断与硬件进行通信的信息，只是想知道，除了中断驱动之外还有其他任何架构吗？在罗伯特·洛夫（Robert Love）的Linux内核书中，他说Linux处理的大部分架构都是中断驱动的，那么其他什么呢？有人举个例子吗？感谢。

Answer 1

对你的问题的简短回答是，只有一个其他模型和轮询。在轮询模型中，系统会反复询问硬件是否发生了任何事情。这种模式的缺点是CPU总是在忙着询问，如果要求它，它只能知道活动。如果它开始做其他事情，它可能会错过一个动作（因为它不是在行动时要求活动）。

答案越久：

如果你考虑一下，实际上只有两种可能的系统：轮询（pull）和事件驱动（push）。在前者中，您询问硬件是否发生了任何事情，而在后者中，硬件会告诉您。换句话说：前者中的代理是CPU / OS，后者中是硬件。由于有两方，每方都可以做两件事之一，这意味着我们只能有两种类型的系统（推/中断和拉/轮询），加上混合（中断驱动和轮询基于不同时期或不同背景下。）

可以想象有多种方法可以实现这三种系统中的任何一种，并且可以将它们视为不同的模型，即使它们真正实现了可能的系统之一。不过，我想这并不是你想要的。

Answer 2

在较低的水平，投票是主要的选择。然而，在架构上，主要方法是单片方式，其中中断直接驱动设备驱动程序和微内核，其中设备驱动程序可以是在硬件事件发生时由内核通知的单独进程。中断发生，但它们由一个非常小的内核管理。我怀疑这是你的引用所指的差异。轮询不再常见。最着名的基于微内核的操作系统之一是Minix，因为它用于教学。

Answer 3

我猜测，它是一些硬实时系统，而不是使用异步中断，系统在明确定义的时间（可能是周期性的）检查（轮询）I / O设备的状态。如果设备未就绪或处于意外状态，系统将报告故障。

Answer 4

我将轮询架构等同于确定性的过程方向，并将中断驱动到随机过程方向。根据自己的优点，两者都不是更好，一般都需要这两者。这取决于外部任务和接口。系统通常必须允许许多进程的交互，并且规划体系结构以在可能满足要求的情况下对进程上下文中的随机性进行分区，同时经历必须定期服务且无随机性的随机服务约束。糟糕的设计会随机违反某些面向时序约束的服务，而不会在功能困境中留下软件级别的解决方案。使用离散事件仿真建模，随机过程使用额外的复杂性建模，而使用连续函数可以更简单地分析确定性过程方向。