interruptible_sleep_on与sleep_on

这几天有网友讨论这个问题，我也没搞的太清楚，谈谈我的目前的看法。
    interruptible_sleep_on与sleep_on区别在于前者可能由信号唤醒，而后者只是wakeup函数可以唤醒。
    interruptible_sleep_on与sleep_on都遵循栈式法则，先等的后唤醒，*p是最后入栈的进程，调用wakeup时p第一个被唤醒；需要注意的是，唤醒整个等待队列需要一个过程，一个进程醒后，唤醒下一个，直到最后一个。在这一过程中，可能有其他进程又要求进入这一等待队列。对sleep_on而言，这没有关系，调用wakeup之前入栈的进程继续自己的唤醒过程（要唤醒的下一个进程在本进程的tmp中保存），调用wakeup之后的进程则更改了*p，在队列中等待，直到下次再调用wakeup时才能醒来。对interruptible_sleep_on则不同。由于信号可能唤醒位于队列中间的某个进程，为了保证栈式管理，Linus做了179－186行的特殊处理。这样，即使中间某个进程先醒了，他也必须把*p唤醒，自己继续睡眠，产生的效果跟wakeup调用一样。在唤醒过程中，如果没有其他进程又要求进入这一等待队列，那么这段
代码没有任何问题。但是，如果有其他进程又要求进入这一等待队列，问题就来了。假设原来队列中的进程是a->b->c->d。*p指向a.调用wakeup或来了一个信号后，a将醒来，并唤醒b.但b不一定能立即运行，此时*p=NULL。假设在b运行前，进程e调用interruptible_sleep_on，则*p指向e而tmp=NULL,e把自己阻塞后，b将运行。由于此时满足if(*p&&*p!=current)，b将唤醒位于栈顶的e,自己进入睡眠。但当e运行时，由于它的tmp=NULL,它将无法唤醒b，事实上，bcd再也无法找到了，他们的信息“丢失了”。
    如果我们把*p=NULL,改为*p=tmp，把wakeup中*p=NULL删掉，则不存在上述问题。但又带来新的问题，就是无法确定队列的“尾”了。因此，这一方案也不可行。
    其实，问题的关键在于，我们无法判断醒来的进程是位于一个“正常”的等待队列中，还是在一个正在“醒过来”的残余队列中。要彻底解决这几个函数的问题，可能要做大手术了。我还没找到简洁的办法。我想的办法是与等待队列并行一个状态队列，利用这一队列的值确定对应进程处于哪个状态。究竟是不是这样，还要请斑竹和各位高手指点。