仅单线程可进入时，为何用带条件的等待队列而非全局指针唤醒？

好问题！咱们先把代码里的逻辑理清楚，再拆解这个疑问：

首先看foo_read的流程：线程拿到信号量进入临界区后，给硬件发送了读取命令（outb(DEV_FOO_READ, DEV_FOO_CONTROL_PORT)），但硬件不会立刻返回数据——得等硬件完成读取后触发中断，在foo_interrupt里把数据存到foo->data，再置位intr=1。这时候当前线程不能傻等，得有合理的方式让出CPU，直到条件满足再继续执行。

等待队列的核心作用（为什么不能用全局指针替代） #

• 高效利用CPU资源：调用wait_event_interruptible会让当前线程进入休眠状态，主动把CPU让给其他需要运行的线程。如果换成轮询intr标志或者用全局指针手动挂起，要么持续浪费CPU资源（轮询），要么需要自己实现复杂的休眠逻辑，很容易出错。
• 支持可中断的系统调用：wait_event_interruptible允许线程被信号中断（比如用户按Ctrl+C），返回-ERESTARTSYS让系统调用可以优雅重启，这是符合POSIX规范的行为。自己用全局指针处理的话，要实现同样的信号响应逻辑会非常繁琐，稍有不慎就会导致线程无法被中断。
• 扩展性与规范性：虽然现在你的信号量初始值是1，只能有一个线程进入临界区，但如果未来需求变化（比如允许多个线程等待硬件就绪），等待队列可以无缝支持。而全局指针只能保存一个线程，一旦有多个线程等待，就会出现指针被覆盖，导致部分线程永远无法被唤醒的问题。
• 分离互斥与条件等待：信号量解决的是临界区互斥问题（保证同一时间只有一个线程操作硬件寄存器），等待队列解决的是条件等待问题（等待硬件数据就绪的条件满足）。这是两个完全不同的同步需求，不能互相替代。

用全局指针*curr的潜在问题 #

如果尝试用全局指针保存当前线程，会遇到一堆棘手的问题：

1. 手动休眠的风险：要让线程休眠，你需要调用set_current_state(TASK_INTERRUPTIBLE)再调用schedule()，如果顺序错了或者没正确处理状态，线程可能会进入不可唤醒的状态。
2. 同步问题：全局指针本身需要额外的锁来保护读写，不然在多线程场景下（哪怕现在是单线程，未来可能扩展）会出现数据竞争，导致错误。
3. 中断唤醒的安全性：内核的等待队列机制已经和中断上下文做了安全整合，wake_up_interruptible可以安全地从中断里唤醒线程。手动用全局指针的话，你需要确保唤醒操作的原子性，很容易引入竞态BUG。

简单来说：信号量管“谁能进门”，等待队列管“进门后什么时候能继续走”，两者配合才是内核处理异步IO场景的标准、高效、安全的做法。

内容的提问来源于stack exchange，提问作者nomilk