在嵌入式 Linux 驱动开发中并发控制与中断处于极其重要的核心地位。本文我将结合 CPU 的行为与操作系统的调度深入分析 spinlock 和 mutex 的本质区别以及 Linux 中断上下半部。1. 上下文的概念在深入探究锁和中断之前我们必须先了解 Linux 内核的两种核心执行流这里先简单概括一下进程上下文代表着某个具体的进程在执行有对应的task_struct。进程上下文中允许休眠因为调度器知道休眠后该去唤醒谁上下文切换是安全的。中断上下文当发生硬件中断时会强行打断当前进程的执行。中断上下文其实是借用了被中断的进程的内核栈并没有自己独立的进程实体也就是task_struct因此中断上下文中是绝对禁止休眠的如果引发休眠调度器将永远无法重新唤醒它直接导致系统崩溃。下面我们逐个深入解析。1.1 进程上下文要学习进程上下文我们必须知道current宏current是 Linux 内核中用于获取当前正在运行进程的task_struct结构体指针的宏。current可以用于定位当前进程返回struct task_struct *指针指向当前 CPU 上正在执行的进程描述符。在内核中通常用于读取或修改进程状态、PID、权限、信号、调度属性等信息。此外每个 CPU 都独立维护自己的current无锁开销低。我们通常都知道进程上下文中允许休眠但是这里面其实有着很多的细节当进程上下文中调用malloc或者mutex_lock若资源不足内核就会调用schedule。然后调度器会将当前 CPU 的寄存器还有程序计数器、栈指针压入该进程的内核栈这是为了在找回该进程的时候能接着上次休眠的地方继续执行并将进程状态设为TASK_INTERRUPTIBLE或TASK_UNINTERRUPTIBLE然后放入等待队列。schedule()会找到下一个可运行的进程切换页表并恢复其寄存器。当资源可用时唤醒函数会把原先休眠的进程移回运行队列调度器下次运行时能从之前休眠的代码位置继续执行。关键点就在于内核有current指针在进程上下文切换时current就从旧进程的task_struct切换到新的进程的task_struct。1.2 中断上下文上面我们提到如果在中断上下文中引发休眠调度器将无法重新唤醒它这是为什么呢我们从调度器的视角来看中断上下文并没有task_struct当它调用schedule时调度器并不知道要把哪个进程切出去更不知道这个执行流是谁。它找不到对应的task_struct来保存状态。因此从逻辑上讲调度器在这种情况下是无法进行调度的。即使强行切换了中断返回时CPU 需要恢复现场但由于没有task_struct记录中断的栈帧CPU 不知道应该回到哪里去。因此Linux 内核对于这种尝试在不能休眠的位置进行可能触发休眠的操作提出了应对的方法Linux 内核中如果中断上下文中调用了可能休眠的函数比如mutex_lock内核的锁校验机制CONFIG_DEBUG_ATOMIC_SLEEP会在编译时或运行时检测到in_atomic()为真直接触发BUG: scheduling while atomic。这个错误的本质是你试图在一个不能进行进程切换的环境里执行一个可能触发进程切换的操作。1.3 让内核崩一次为了验证在中断中睡眠是否会导致程序崩溃我进行了下面实验我用我前两天写的按键input子系统驱动进行测试在按键按下或抬起时会进入中断我在中断处理函数中加入msleep如下图我原以为加载驱动后按下按键程序会崩溃内核打印错误日志因此我特意开了两个终端一个用来加载模块一个用来查看实时内核日志但是结果令我大吃一惊请看吧如图所示在按下按键之后内核也是如愿以偿的崩了我尝试了好几次前面几次甚至连内核日志都没来的及打印SSH 就断开了随后板上象征着系统正常运行的闪烁着的绿灯也彻底熄灭了。我试到第四次才成功看到了内核日志打印的错误信息。2. 并发与同步机制在 Linux 内核中保护共享资源的两种最基本锁机制是自旋锁和互斥锁。它们的核心差异不仅在于名字更在于获取不到锁时的行为和对系统造成的开销。2.1 行为对比对于自旋锁当拿不到锁时CPU 会进入死循环原地空转不断尝试获取它会严重消耗 CPU 资源但并不产生上下文切换的开销。此外拿到自旋锁之后还会关闭当前 CPU 的内核抢占功能导致该 CPU 无法响应其他的中断若等待时间过长会严重拖慢系统的反应速度。对于互斥锁当拿不到锁时当前进程会被放入等待队列主动调用schedule让出 CPU 进入休眠它会引发上下文切换从而导致操作系统调度别的任务。上下文切换的开销很大涉及到寄存器的保护和恢复Cache 的失效等等。2.2 适用场景总结基于上面两种锁机制的特性可以归纳一下他们各自的适用场景自旋锁适用于临界区代码极短锁很快就能被释放的场景。适用于中断上下文由于中断上下文禁止睡眠所以只能使用自旋锁。互斥锁适用于临界区较长或者临界区内包含可能引起休眠的操作比如复制大量数据到用户空间、分配内存等。互斥锁只能用于进程上下文。2.3 死锁问题简述如果在中断中不仅要加锁还涉及到与普通进程共享资源那么就不能使用普通的自旋锁必须使用spin_lock_irqsave。spin_lock_irqsave在获取锁的同时会关闭本地 CPU 的硬件中断并保存中断状态。如果只用普通的spin_lock进程拿到锁还没释放时 CPU 突然来了中断中断处理函数中又去申请同一把锁就会导致死锁。3. 中断的上下半部机制中断处理的原则是越快越好因为在中断处理期间硬件中断是被屏蔽的。但是此时如果网卡收到大量数据需要处理或者读取传感器需要一定的时间怎么办为了能够解决既要响应快又要及时处理耗时任务的矛盾内核引入了中断上下半部机制。其中上半部在中断上下文中执行只做最紧急的事情比如读取硬件寄存器清除中断标志位将数据存入内存并触发下半部然后立刻返回。而下半部中负责完成中断相关的剩余耗时工作执行环境也相对宽松一点。常见的下半部实现方式有 Tasklet 和 Workqueue他们的对比如下表4. 现代 Linux 内核的演进方向在早期的内核代码中Tasklet 使用非常广泛。但在现代 Linux 内核中Tasklet 正在被逐步废弃这是由于其设计缺陷容易导致软中断延迟不可控影响系统的实时性。此外现代内核优化了 Workqueue性能已足够强了所以以后习惯上还是改用 Workqueue 比较好。内核还引入了request_threaded_irq接口也就是中断线程化直接将下半部放入一个独立的、可调度的内核线程中去执行。这种方式既解决了休眠问题又能让操作系统统一管理调度优先级极大地提升了系统的实时性。最后大家可以尝试思考两个简单的问题在硬件中断处理函数中如果我要等待一个 I2C 传感器回应可以调用msleep(10)吗Spinlock 既可以在中断上下文使用又可以在进程上下文使用那为什么还要有 Mutex知道答案的可以打在评论区哦~