最近一套方案涉及到内核线程之间的同步，用到了函数wait_event_interruptible_timeout函数，大致是这样：

A：是一个后台的线程，平常没事就睡觉，有时被唤醒，或者每5分钟醒一次看看；

B：普通线程，负责唤醒后台的线程让它干活！

此处唤醒的操作使用到的函数是wake_up，然后进程A使用wait_event_interruptible_timeout让自己睡觉。下面详细分析其中的机制：

wait_event_interruptible_timeout: sleep util a condition get true or a timeout elapses

记得以前看侯捷老师那本MFC架构分析时，最吸引人的概念是事件触发模型，事件触发模型很好理解，但是AA事件发生了，那么BB事件就应该发生，在我们这个例子里就是B普通线程发生了，那么就让A发生！

具体是怎么实现的？

1）wait_event_interruptible_timeout是把调用这个函数的进程链入到一个list中，并且

最重要的结构体是wait_queue_head_t，这个结构体包含两个成员变量：spin_lock lock 和 struct list_head task_list

可知这个结构体的目的其实也是比较简单的：就是把一个进程插入到一个队列中去！

函数层层递进，其实调用的是 wait_event 函数，这个函数其实就是一个死循环：

schedule_timeout是什么意思。不断地把函数添加到wait_queue_head_t->task_list中去，然后调用schedule_timeout调度，这个schedule_timeout是什么意思？就是不断地调度出去，但是这个线程目前在两个地方存在，一个是内核的调度队列，一个是等待队列的链表中。那么问题来了，在这里一般问题是说[可中断的等待，不可中断的等待]有什么区别？

在非可中断的情况下，是怎么实现的事件触发，其实也是不断地去检查condition是否成立，那么这个检查的时间粒度肯定是比较低的。到底是多少？

在timeout之间的位置，怎么识别事件是否到来！

uninterruptible状态是指：uninterruptible的线程只能通过wake_up的方式【uninterruptible也是在schedule的视野范围之内！只是调度其肯定不会选你就对了】

调度器

wait_event_interruptible_timeout