1. struct wait_queue *wq = NULL; /* global variable */
2. while ( is_full ) {
3. interruptible_sleep_on( &wq );
4. }
5. write_to_buffer();

interruptible_sleep_on( &wq ) 是用来将目前的 process，也就是要求写资料到 buffer 的 process放到 wq 这个 wait_queue 里。在 interruptible_sleep_on 里，则是最后会呼叫 schedule() 来做 schedule 的动作，也就是去找另一个 process 来执行以维持系统的运作。当执行完 interruptible_sleep_on 之后，要求 write 的 process 就会被 block 住。那什么时候会恢复执行呢 ? 这个 process 之所以会被 block 住是因为 buffer 的空间满了，无法写入。但是如果有人将 buffer 的资料读取掉，则 buffer 就有空间可以让人写入。所以，有关于叫醒 process 的动作应该是在 read buffer 这方面的程序代码做的。

1. extern struct wait_queue *wq;
2. if ( !is_empty ) {
3. read_from_buffer();
4. wake_up_interruptible( &wq );
5. }

以上的程序代码应该要放在 read buffer 这部分的程序代码里，当 buffer 有多余的空间时,我们就呼叫 wake_up_interruptible( &wq ) 来将挂在 wq 上的所有 process 叫醒。请记得，我是说将 wq 上的所有 process 叫醒，所以，如果如果有10个 process 挂在 wq 上的话，那这 10 个都会被叫醒。之后，至于谁先执行。则是要看 schedule 是怎么做的。就是因为这 10 个都会被叫醒。如果 A 先执行，而且万一很不凑巧的，A 又把 buffer 写满了，那其它 9 个 process 要怎么办呢? 所以在 write buffer 的部分，需要用一个 while 来检查 buffer 目前是否满了.如果是的话，那就继续挂在 wq 上面.

在使用 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一下就立刻会重新进入运行调度。 
  
2. 关于wait_event_interruptible的返回值 
  
根据 wait_event_interruptible 的宏定义知：

1) 条件condition为真时调用这个函数将直接返回0，而当前进程不会被 wait_event_interruptible和从runqueue队列中删除。 
  
   2) 如果要被wait_event_interruptible的当前进程有nonblocked pending  signals, 那么会直接返回-ERESTARTSYS(i.e. -512)，当前进程不会被wait_event_interruptible 和从runqueue队列中删除。 
  
   3) 其他情况下，当前进程会被正常的wait_event_interruptible，并从runqueue队列中删除，进入TASK_INTERRUPTIBLE状态退出运行调度，直到再次被唤醒加入runqueue队列中后而参与调度，将正常返回0。 
  
附1：wait_event_interruptible  宏

1. #define wait_event_interruptible(wq, condition)    \
2. ({                                                 \
3. int __ret = 0;                                  \
4. if (!(condition))                               \
5. __wait_event_interruptible(wq, condition, __ret); \
6. __ret;                                         \
7. })

注: C语言中{a,b, ..., x}的的值等于最后一项，即x，因此上述宏的值是 __ret。   
  
附2：wait_event_interruptible()和 wake_up的等效代码

1. wait_event_interruptible(wq, condition) /*等效没有考虑返回值*/
2. {
3. if (!(condition))
4. {
5. wait_queue_t _ _wait;
6. init_waitqueue_entry(&_ _wait, current);
7. add_wait_queue(&wq, &_ _wait);
8. for (;;)
9. {
10. set_current_state(TASK_INTERRUPTIBLE);
11. if (condition)
12. break;
13. schedule();  /* implicit call: del_from_runqueue(current)*/
14. }
15. current->state = TASK_RUNNING;
16. remove_wait_queue(&wq, &_ _wait);
17. }
18. }
19. void wake_up(wait_queue_head_t *q)
20. {
21. struct list_head *tmp;
22. wait_queue_t *curr;
23. list_for_each(tmp, &q->task_list)
24. {
25. curr = list_entry(tmp, wait_queue_t, task_list);
26. wake_up_process(curr->task);
27. /* implicit call: add_to_runqueue(curr->task);*/
28. if (curr->flags)
29. break;
30. }
31. }

参考：

http://linux.chinaunix.net/techdoc/develop/2008/01/11/976385.shtml

http://linux.chinaunix.net/techdoc/system/2009/07/04/1121922.shtml

http://zhidao.baidu.com/question/178113239.html