linux循环睡眠等待中断怎么实现

Linux 中的进程睡眠状态有两种：一种是可中断的睡眠状态，其状态标志位为TASK_INTERRUPTIBLE；另一种是不可中断的睡眠状态，其状态标志位为TASK_UNINTERRUPTIBLE。

可中断的睡眠状态的进程会睡眠直到某个条件变为真，如产生一个硬件中断、释放进程正在等待的系统资源或是传递一个信号都可以是唤醒进程的条件。

不可中断睡眠状态与可中断睡眠状态类似，但是它有一个例外，那就是把信号传递到这种睡眠状态的进程不能改变它的状态，也就是说它不响应信号的唤醒。

以下是根据一些资料和个人理解总结的，如有错误希望指出。

首先需要明确的是，这里的中断指的是硬件中断。

从事实上说明 有下面这些理由。

硬件中断本身就是用来作为处理紧急事件的一种方法，所以硬件中断服务程序应该尽量的快。不应该睡眠

硬件中断服务程序会打断某个无辜的进程(甚至是另一个中断服务程序)。所以它应该尽量快(突然被打断运行已经够无辜了，总不能还让一直等待吧)

硬件中断是无法预测的，如果在中断服务程序中睡眠就会导致睡眠过程中该中断请求的丢失。(linux中一个中断处理程序在运行时，相应中断线会被屏蔽掉)

要理解为什么硬件中断处理程序中不能睡眠的内在机制。需要理解下面这些概念。

1 linux内核的工作模式 linux内核有两种工作模式，进程上下文和中断上下文。

1.1 进程上下文指内核代表进程执行

比如进程执行系统调用产生异常陷入内核后，内核就代表该进程执行 *** 作。可以通过current宏关联到当前进程，

因为陷入内核时进程造成的或需求的，所以内核的执行与当前进程相关。所以说他代表该进程执行

1.2 执行一个硬件中断处理程序时就处于中断上下文

中断上下中和进程没什么关系(虽然此时current指向被中断的进程)。这也容易理解，因为硬件中断随时

都有可能发生。不像上面提到的像系统调用之类的异常是由于程序执行某些指令造成的，所以陷入

内核后，因为要坐的工作基本都是和当前这个进程相关的(因为是他执行一些指令导致产生的异常)，

所以我们说内核代表进程执行。

但是硬件中断的产生完全无法预测，所以谁也不知道硬件中断将会打断哪个进程。所以硬件中断服务程序与进程无关

它处于中断上下文中

2 异常和硬件中断的区别

2.1 异常属于中断的一种，和硬件中断的区别在与它是"同步"，是由于执行一些指令造成的。如除0

或者执行过程中产生缺页，以及软中断实现的系统调用。(这也是叫“同步中断”的原因，因为指令的执行是要时钟同步的)。

当执行的指令会陷入内核时，就会运行在进程上下文中。内核代表进程

2.2 硬件中断时一种 异步中断，他随时都可能发生，无法预测。中断执行时处于中断上下文中。

综上，linux中硬件中断服务程序不能睡眠的原因在与。执行硬件中断服务程序时，内核处于中断上下文

中，此时内核与进程无关。如果睡眠后就不能调度回来了。因为调度程序调度的是进程，而之前的硬件中断服务程序却是和进程无关的

至于中断为什么不能进入休眠，今天再网上查阅并总结了一下：

中断处理的时候,不应该发生进程切换,因为在中断上下文中,唯一能打断当前中断handler的只有更高优先级的中断,

它不会被进程打断(这点对于softirq,tasklet也一样,因此这些bottom half也不能休眠),如果在中断上下文中休眠,则

没有办法唤醒它,因为所有的wake_up_xxx都是针对某个进程而言的,而在中断上下文中,没有进程的概念,没有相应的

task_struct(这点对于softirq和tasklet一样),因此真的休眠了,比如调用了会导致阻塞的例程,内核几乎肯定会死.

---