首页/计算机组成原理/I/O系统/程序查询方式 🔗 在 Obsidian 中打开
计算机组成原理 · I/O系统

程序查询方式

难度 ★★★重要度 ★★★★ 考查频率 低题型 选择 轮询IO方式等待CPU利用率
速查
最简单的 I/O 方式:CPU 主动轮询设备状态寄存器,就绪才传送。CPU 在等待期间一直忙等(busy-waiting),利用率低,但硬件最简单,无需中断机制。

概述

程序查询方式(Programmed I/O / Polling)是最简单的 I/O 控制方式。CPU 主动查询设备状态,等待设备就绪后进行数据传输,整个 I/O 过程中 CPU 被占用。

工作原理

1. CPU 向设备发命令(启动设备)
2. 不断读取状态寄存器(轮询)
3. 检查 Ready 位:
   - Ready=0 → 回步骤2继续查询
   - Ready=1 → 设备进行数据传输
4. 读/写数据
5. 未完成 → 回步骤2;完成 → 结束
// 输入操作(伪代码)
void input_polling() {
    out(CONTROL, START_CMD);
    while (1) {
        status = in(STATUS);
        if (status & READY_BIT) { data = in(DATA); break; }
    }
}

程序查询方式的特点

优点

  • 实现简单,硬件需求最少
  • 控制直接,CPU 完全管理
  • 可靠性高,适用于低速设备/简单系统

缺点

  • CPU 利用率低:等待期间空转
  • 实时性差,不能及时响应其他事件
  • 不能多设备并发
  • 效率低,大量时间浪费在查询上
CPU 利用率 = 1 - R × (Tquery + Ttransfer) / Ttotal
例:设备每 100ms 传 1 字节,每次查询 1μs
CPU 用于查询 ≈ 100ms → 利用率极低

多设备查询

CPU 按固定顺序循环查询各设备。问题:响应延迟不均、高优先级设备得不到及时服务。

按优先级查询(先查高优先级设备)缓解,但仍是串行、不能真正并发。

与其他 I/O 方式对比

特性程序查询程序中断DMA
CPU 占用高(等待)中(处理)
硬件复杂度
传输单位字/字节字/字节数据块
CPU 利用率
适用场景低速设备中速设备高速设备
并发能力有限

程序查询的延迟计算

最大响应延迟:最坏情况 CPU 刚查完某设备后它才就绪,需等一个完整查询周期。

查询周期 = Σ(每个设备的查询时间)
最大响应延迟 = 查询周期 - 当前设备查询时间
平均响应延迟 ≈ 查询周期 / 2

易错点

必记
  1. 查询方式 CPU 在等待期间一直忙等(busy-waiting)
  2. CPU 不能做其他工作,利用率低。
  3. 查询顺序影响各设备响应时间。
  4. 超时机制必要,防止设备故障导致死循环。
  5. 程序查询不需要中断机制
  6. 数据传输是逐字/字节,不是数据块。
  7. 简单但低效,现代系统主要用中断和 DMA。

记忆卡片

程序查询的CPU状态?
等待期间一直忙等(busy-waiting),不能做其他事
最大缺点?
CPU 利用率低,大量时间浪费在轮询上
需要中断机制吗?
不需要,纯轮询,硬件最简单
适合什么场景?
低速设备、简单系统、调试初始化阶段
传输单位?
逐字/字节,不是数据块
为何需要超时?
防止设备故障导致 CPU 死循环

交互动画 · 轮询循环(未就绪 vs 就绪)

轮询循环:未就绪则反复查询;就绪才传输 发送命令 读状态寄存器 传输数据 完成 未就绪 → 回到「读状态」继续查询
选择设备状态,查看轮询循环走向
点击上方按钮开始
未就绪:走回环箭头持续轮询(CPU 忙等);就绪:经传输数据到完成,CPU 才释放。

相关知识点

program-interrupt-mode dma-mode io-interface

↑ 以上为站内 HTML 相对链接(纯网页可浏览);本页右上「在 Obsidian 中打开」跳回源笔记。