深入 Linux 内核:从 wait_event 到进程睡眠,字符设备阻塞读全解析

你写过一个阻塞 read 的字符设备吗？

用户态 read(fd, buf, n) 一直不返回，直到内核端有数据可读。这个"一直不返回"就是 wait_event 干的活。

我手边有个项目，需要从内核往用户态推送事件，第一版用的轮询（用户态每 100ms poll 一次），CPU 占用 3%。改成阻塞 read 之后降到 0%。背后就是 wait_event。

先写一个最小字符设备

// chardev_wait.c
#include <linux/module.h>
#include <linux/cdev.h>
#include <linux/wait.h>
#include <linux/uaccess.h>

#define BUF_SIZE 32

static char msg[BUF_SIZE];
static int msg_len;
static DECLARE_WAIT_QUEUE_HEAD(read_wq);
static dev_t dev_num;
static struct cdev my_cdev;

static ssize_t my_read(struct file *filp, char __user *buf,
                       size_t count, loff_t *ppos)
{
    // 没有数据就睡，有数据就读
    wait_event_interruptible(read_wq, msg_len > 0);
    if (copy_to_user(buf, msg, msg_len))
        return -EFAULT;
    int ret_len = msg_len;  // 先保存长度
    msg_len = 0;  // 读完清空
    return ret_len;
}

static ssize_t my_write(struct file *filp, const char __user *buf,
                        size_t count, loff_t *ppos)
{
    if (count > BUF_SIZE)
        count = BUF_SIZE;
    if (copy_from_user(msg, buf, count))
        return -EFAULT;
    msg_len = count;
    wake_up(&read_wq);  // 有数据了，叫醒等着的人
    return count;
}

static const struct file_operations my_fops = {
    .owner = THIS_MODULE,
    .read  = my_read,
    .write = my_write,
};

整个阻塞读的机制就在两行代码：

// 读端：没数据就睡
wait_event_interruptible(read_wq, msg_len > 0);

// 写端：写完数据叫醒
wake_up(&read_wq);

一个字符设备搞定了一个生产者-消费者模型。

read 阻塞时到底发生了什么

时序图画了完整流程。拆成三步：

第一步，检查条件。 wait_event_interruptible 先检查 msg_len > 0。如果有数据，直接返回，不睡。这就是为什么 wait_event 是一个"可能睡也可能不睡"的函数。

第二步，入队并改状态。 prepare_to_wait_event() 把当前进程包装成 wait_queue_entry，加到 read_wq 队列尾部，然后调用 set_current_state(TASK_INTERRUPTIBLE) 把进程状态改成可中断睡眠。

状态改完之后，调度器就不会再选中这个进程运行了——调度器只调度 TASK_RUNNING 的进程。

第三步，让出 CPU。 schedule() 被调用，当前进程让出 CPU，调度器选下一个进程跑。此时 ps aux 里看到这个进程状态是 S（可中断睡眠，因为代码用的是 interruptible 版本），wchan 显示它睡在 wait_event 上。如果用的是不带 interruptible 的版本，状态会是 D（不可中断睡眠）。

进程不占任何 CPU，就这么挂着，直到 wake_up 来叫醒它。

（文中时序图里标注的

等待队列长什么样

wait_queue_head 本质就是一个带自旋锁的链表。链表上每个节点是一个 wait_queue_entry，记录着等这个事件的进程信息：

• private：指向 task_struct，内核通过这个找到要叫醒的进程
• state：进程睡眠状态（TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE）
• func：唤醒回调，默认 default_wake_function，特殊场景可以替换

当多个进程同时 read() 这个设备，它们都会被挂到同一个 read_wq 队列上。write() 调 wake_up 时，内核遍历队列，叫醒第一个进程，第一个读走数据后 msg_len 变回 0，其余进程继续睡。

第三个节点标了红色边框，它的 flags 带了 WQ_FLAG_EXCLUSIVE。带这个标记的进程被唤醒后，wake_up 会停止继续遍历。内核的 epoll 用了这个机制，避免惊群——100 个进程等一个事件，不需要全部叫醒。

超时版本的坑

等一个永远不来事件怎么办？进程就永远挂着了。用 wait_event_interruptible_timeout 加个超时：

ssize_t my_read(struct file *filp, char __user *buf,
                size_t count, loff_t *ppos)
{
    long ret = wait_event_interruptible_timeout(read_wq,
                    msg_len > 0, 5 * HZ);
    if (ret == 0)
        return -ETIMEDOUT;     // 5 秒超时
    if (ret < 0)
        return ret;            // 被信号打断（-ERESTARTSYS）
    // ret > 0，剩余 jiffies，条件满足
    if (copy_to_user(buf, msg, msg_len))
        return -EFAULT;
    msg_len = 0;
    return msg_len;
}

这个接口的返回值设计有个坑：超时返回 0，成功返回非零（剩余 jiffies）。

if (ret == 0)
    // 超时了
else if (ret < 0)
    // 出错了
else
    // 成功，ret 是剩余 jiffies

三种情况，三种返回值语义。第一次用的时候很容易搞反"成功和超时"的判断，我把一个项目里的条件写反了，结果超时的时候正常执行，成功的时候反而不处理——查了半天才发现。

HZ 的值取决于内核配置，用 sysctl kernel.hz 或者看 /boot/config-$(uname -r) 里的 CONFIG_HZ。常见值是 250（每 tick 4ms）或 1000（每 tick 1ms）。

内核里三个真实场景

场景 1：设备驱动里的阻塞读。 上面的字符设备就是标准写法。内核里的 I2C 驱动、SPI 驱动、pipe、fifo 都是这个模式——读端等数据，写端触发唤醒。

场景 2：netlink 广播通知。 内核通过 netlink 往用户态发消息，用户态进程打开 netlink socket 后调用 recvmsg()。内核端发消息时调 netlink_has_listeners() + netlink_sendmsg()，用户态的 recvmsg() 底层就是 wait_event 在等 socket 接收队列有数据。

场景 3：workqueue 完成通知。 有些内核操作是异步的（比如提交一个块设备 I/O），提交后不阻塞，通过 completion 等待完成。completion 底层就是 wait_event，等 done 标志变 1。

// 提交异步 IO
struct completion io_done;
init_completion(&io_done);
submit_bio(READ, bio);

// 等待完成（不占 CPU）
wait_for_completion(&io_done);

wait_for_completion() 展开就是 wait_event(wq, x->done != 0)，加 done--。这是内核线程同步最常用的方式之一。

完整测试

用户态测试代码：

// test.c
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>

int main()
{
    int fd = open("/dev/mychardev", O_RDWR);
    char buf[64];

    printf("read blocking...\n");
    int n = read(fd, buf, 64);  // 阻塞
    printf("got %d bytes: %.*s\n", n, n, buf);
    close(fd);
    return 0;
}

另一个终端写入数据：

echo "hello" > /dev/mychardev

read 立即返回，拿到 "hello"。

ps 看阻塞时的进程状态：

$ ps -eo pid,stat,wchan:30,cmd | grep test
12345 S+   wait_event_interruptible_excl ./test

wchan 显示 wait_event_interruptible_excl，stat 是 S（interruptible sleep）。如果用的是 wait_event（不带 interruptible），状态会是 D（uninterruptible sleep），kill -9 都杀不掉。

为什么选 interruptible 版本

大部分设备驱动的 read 用 wait_event_interruptible 而不是 wait_event，原因很简单：用户可能 Ctrl+C 终止程序。

如果内核代码用了不可中断睡眠（wait_event），用户的 Ctrl+C 信号会排队但无法被处理——进程醒不过来，信号就没机会处理。wait_event_interruptible 让进程在收到信号时能被唤醒并返回 -ERESTARTSYS，用户态的 glibc 会把这个错误码转成 EINTR，read 返回 -1，errno 设为 EINTR，用户程序可以正确退出。

除非是内核线程（不接收信号），否则用户态相关的系统调用实现一律用 interruptible 版本。