在使用 wait_queue 之前有一点需要特别的小心，呼叫 interruptible_sleep_on() 以及 sleep_on() 的 function 必须要是 reentrant。简单的说，reentrant 的意思是说此 function不会改变任何的 global variable，或者是不会 depend on 任何的 global variable，或者是在呼叫 interruptible_sleep_on() 或 sleep_on() 之后不会 depend on 任何的 global variable。因为当此 function 呼叫 sleep_on() 时，目前的 process 会被暂停执行。可能另一个 process 又会呼叫此 function。若之前的 process 将某些 information 存在 global variable，等它恢复执行时要使用，结果第二行程进来了，又把这个 global variable 改掉了。等第一个 process 恢复执行时，放在 global variable 中的 information 都变了。产生的结果恐怕就不是我们所能想象了。其实，从 process 执行指令到此 function 中所呼叫的 function 都应该是要 reentrant 的。不然，很有可能还是会有上述的情形发生。
几点总结：
1. 关于 wait_event_interruptible() 和 wake_up()的使用
读一下wait_event_interruptible()的源码，不难发现这个函数先将当前进程的状态设置成TASK_INTERRUPTIBLE，然后调用schedule()，而schedule()会将位于TASK_INTERRUPTIBLE状态的当前进程从runqueue 队列中删除。从runqueue队列中删除的结果是，当前这个进程将不再参与调度，除非通过其他函数将这个进程重新放入这个runqueue队列中，这就是wake_up()的作用了。
由于这一段代码位于一个由condition控制的for(;;)循环中，所以当由shedule()返回时(当然是被wake_up之后，通过其他进程的schedule()而再次调度本进程)，如果条件condition不满足，本进程将自动再次被设置为TASK_INTERRUPTIBLE状态，接下来执行schedule()的结果是再次被从runqueue队列中删除。这时候就需要再次通过wake_up重新添加到runqueue队列中。
如此反复，直到condition为真的时候被wake_up。
可见，成功地唤醒一个被wait_event_interruptible()的进程，需要满足：
在 1)condition为真的前提下，2) 调用wake_up()。
所以，如果你仅仅修改condition，那么只是满足其中一个条件，这个时候，被wait_event_interruptible()起来的进程尚未位于runqueue队列中，因此不会被 schedule。这个时候只要wake_up一下就立刻会重新进入运行调度。