我要做踩不死的小强！

补充

中断上下文不能睡眠的原因是：

1.中断处理的时候,不应该发生进程切换，因为在中断context中，唯一能打断当前中断handler的只有更高优先级的中断，它不会被进程打断，如果在 中断context中休眠，则没有办法唤醒它，因为所有的wake_up_xxx都是针对某个进程而言的，而在中断context中，没有进程的概念，没 有一个task_struct(这点对于softirq和tasklet一样)，因此真的休眠了，比如调用了会导致block的例程，内核几乎肯定会死。

2.schedule()在切换进程时，保存当前的进程上下文(CPU寄存器的值、进程的状态以及堆栈中的内容)，以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文(在调用中断处理程序后恢复);

但在中断处理程序里，CPU寄存器的值肯定已经变化了吧(最重要的程序计数器PC、堆栈SP等)，如果此时因为睡眠或阻塞操作调用了schedule()，则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。

3.内核中schedule()函数本身在进来的时候判断是否处于中断上下文:

 

背景

由于在多处理器环境中某些资源的有限性，有时需要互斥访问(mutual exclusion)，这时候就需要引入锁的概念，只有获取了锁的任务才能够对资源进行访问，由于多线程的核心是CPU的时间分片，所以同一时刻只能有一个任务获取到锁。

内核当发生访问资源冲突的时候，通常有两种处理方式：

• 一个是原地等待
• 一个是挂起当前进程，调度其他进程执行(睡眠)

自旋锁

Spinlock 是内核中提供的一种比较常见的锁机制，自旋锁是“原地等待”的方式解决资源冲突的。即，一个线程获取了一个自旋锁后，另外一个线程期望获取该自旋锁，获取不到，只能够原地“打转”(忙等待)。

由于自旋锁的这个忙等待的特性，注定了它使用场景上的限制 —— 自旋锁不应该被长时间的持有(消耗 CPU 资源)。

自旋锁的优点

自旋锁不会使线程状态发生切换，一直处于用户态，即线程一直都是active的;不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快。

非自旋锁在获取不到锁的时候会进入阻塞状态，从而进入内核态，当获取到锁的时候需要从内核态恢复，需要线程上下文切换。(线程被阻塞后便进入内核(Linux)调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能)。

自旋锁的使用

在linux kernel的实现中，经常会遇到这样的场景：共享数据被中断上下文和进程上下文访问，该如何保护呢?

如果只有进程上下文的访问，那么可以考虑使用semaphore或者mutex的锁机制，但是现在中断上下文也掺和进来，那些可以导致睡眠的lock就不能使用了，这时候，可以考虑使用spin lock。

在中断上下文，是不允许睡眠的，所以，这里需要的是一个不会导致睡眠的锁——spinlock。

换言之，中断上下文要用锁，首选 spinlock。

使用自旋锁，有两种方式定义一个锁：

动态的：

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!