📚 课程目录第1章 IO模型概述

Linux内核阻塞与非阻塞IO：等待队列与poll机制实战 - 第1节

1.1 为什么需要理解 IO 模型？

在 Linux 内核与嵌入式开发中，IO 操作（如读写文件、网络数据收发、设备驱动交互）是系统性能的核心瓶颈。不同的 IO 模型决定了应用程序如何等待数据、何时被唤醒、以及 CPU 资源的利用效率。理解同步、异步、阻塞、非阻塞这四个基本概念，是掌握等待队列与 poll 机制的前提。

💡 核心观点： “阻塞”与“非阻塞”关注的是调用方在等待资源时的状态；“同步”与“异步”关注的是数据就绪的通知方式。两者组合形成四种 IO 模型。

阻塞与非阻塞描述的是系统调用发起后，进程/线程是否被挂起。

  🔧 内核视角： 阻塞 IO 是等待队列机制的经典应用。当设备无数据时，驱动调用 wait_event_interruptible() 将当前进程加入等待队列并调度出去；数据到达时，驱动调用 wake_up() 唤醒进程。

同步与异步描述的是数据就绪或 IO 完成时，如何通知应用程序。

⚠️ 常见误区： 很多人认为 epoll 是异步 IO。实际上 epoll 只是同步 IO 的多路复用——它只负责通知“数据就绪”，应用程序仍需自己调用 read() 拷贝数据。真正的异步 IO（如 io_uring）由内核完成数据拷贝后直接通知。

将阻塞/非阻塞与同步/异步交叉，得到四种经典 IO 模型。下面的 SVG 图展示了它们的核心流程差异。

在 Linux 内核中，阻塞 IO 的实现依赖 等待队列（wait_queue），而非阻塞 IO 的“数据是否就绪”查询则依赖 poll 机制。两者是驱动开发中最核心的同步原语。

等待队列（wait_queue）：用于管理因等待某个条件而睡眠的进程。驱动通过 wait_event_interruptible() 让进程睡眠，通过 wake_up() 唤醒。
poll 机制：实现 file_operations 中的 .poll 回调，返回设备当前可读/可写状态。用户态的 select()/poll()/epoll() 最终都会调用驱动的 .poll 方法。

  📌 课程主线预告： 本章后续将深入等待队列的初始化、睡眠、唤醒流程，以及 poll 回调的注册与事件通知机制。你将亲手编写一个使用等待队列实现阻塞读、使用 poll 实现非阻塞查询的虚拟字符驱动。