从Cortex-M3的MSP 和PSP谈Linux能否在中断中使用Sleep

1、Cortex-M3 的PSP和MSP

曾经在STM32上使用过RT thread和uC/OS，对于任务切换代码一直是一知半解，没有自己手动写出来过，对于任务切换后的ORR   LR, LR, #0x04; Ensure exception return uses process stack也不是很理解，一次偶然的机会，遇到网上有人问这个问题，才去深入研究一下。Cortex‐M3 拥有两个堆栈指针，然而它们是banked，因此任一时刻只能使用其中的一个：

主堆栈指针（MSP）：复位后缺省使用的堆栈指针，用于操作系统内核以及异常处理例程（包括中断服务例程）。

进程堆栈指针（PSP）：由用户的应用程序代码使用。堆栈指针的最低两位永远是0，这意味着堆栈总是4 字节对齐的。

由此可以看出，在一个系统里有两大部分，一是操作系统和中断，一是用户用户程序，他们使用的资源是不一样的，在任务调度的时候，中断（任务调度的中断）返回到用户程序所以要使用PSP。

2、Linux系统中断中能否使用Sleep

这个是我一个同学的面试题，说给我的时候我第一反应是可以，在中断中使用Sleep不会使得中断挂起，在任务中使用Sleep会将当前的任务挂起，Sleep的原理是根据Sleep的参数N暂停当前的任务，N个周期（也可能是MS）后将该任务置为就绪态，换言之，Sleep实际上就是一次任务调度，那为什么不可以的，我还进一步解释，在uC/OS中，在中断的结尾都会调用OS_INT_EXIT()函数来进行任务的调度，Sleep与OS_INT_EXIT只是函数名不同，最终都是会调用调度器的。

哈哈，对于正确答案我想大家都猜到了，那就是当然不可以的啦，但是我的解释貌似天衣无缝哦，那是因为我是使用uC/OS来解释的，Linux系统当然和uC/OS不同，回头看看，在Cortex-M3的硬件中有MSP和PSP，那么他的设计初衷是什么，那就是操作系统（包括中断）和用户程序分（隔）离，或者说是保护操作系统，防止遭到破坏，在这种思想下，Linux系统中，对于涉及到系统核心的东西使用保护的，不是所有的地方都是可见的，uC/OS是系统和应用程序一起编译，只要是全局变量都是可以见的，而Linux不同，在中断上下为中，current宏是无效的，所以此时是无法进行任务调度的。

以上是我结合Cortex-M3内核的硬件，从隔离和保护的思想去解释为什么Linux下，中断中不能使用Sleep。下面给出我查阅资料的官方解释，主要是《linux内核设计与实现》上的内容。

1、进程上下文

可执行代码是进程的重要组成部分，这些代码从一个可执行文件载入到进程的地址空间执行。一般的程序在用户空间执行，当一个程序执行了系统调用或者触发了某个异常，它就陷入了内核空间，此时，我们称内核代表进程执行并处于进程上下文中。在此上下文中current宏是有效的。（系统调用和异常处理程序是对内核明确定义的接口，进程只有通过这些接口才能陷入内核执行—对内核的所有访问都必须通过这些接口。

2、中断上下文

当执行一个中断处理程序时，内核处于中断上下文中，中断上下文和进程并没有任何瓜葛。与current宏也是不相干的（尽管它会指向被被中断的进程）。因为没有后备进程，所以中断上下文不可以睡眠，否则又怎能再对它重新调度呢？因此，不能从中断上下文中调用某些函数（就是被中断处理程序限制的函数，Sleep就是其中一个）。

事实上，除了MSP和PSP之外，处理器很多的寄存器都是banked，用户程序和中断程序使用的寄存器是不同的，所以进程上下文和中断上下文环境是不同的，如果在中断上下文中进行任务调度，是没有办法保存进程上下文信息的，所以如果这个时候调度就是有问题的，软件上阻止了该调度——即current宏此时是不可见的，从而无法进行调度。