不能在Linux内核中使用std::mutex或std::atomic，因内核无C++标准库链接和ABI支持，所有同步原语须来自kernel头文件；混用会导致编译/链接失败或内存屏障语义冲突。
不能在 Linux 内核开发中用 C++ 的 std::mutex 或 std::atomic —— 内核空间不链接 C++ 标准库，也没有 ABI 支持。所有同步原语必须来自 <linux></linux> 和 <linux></linux> 等内核头文件。
为什么不能混用用户态 C++ 同步原语和内核同步机制
内核是纯 C 编写的单地址空间环境，没有异常处理、RTTI、new/delete 运行时，也不提供 std::thread 所依赖的调度上下文。试图在 .c 或 .o 模块里 include <mutex></mutex> 会导致编译失败或链接错误，例如：
ERROR: modpost: "std::mutex::lock" [drivers/mydrv.ko] undefined!
即使强行用 extern "C" 包裹内核头文件，std::atomic_flag 的底层实现（如 x86 上的 lock xchgb）也与内核的 arch_spin_lock() 内存屏障语义不兼容，可能破坏锁的 acquire/release 行为。
spinlock_t 在中断上下文中的正确用法
自旋锁唯一能安全跨上下文使用的场景是：保护被进程上下文和硬中断同时访问的共享数据（如设备寄存器、状态标志）。但必须匹配中断禁用级别：
立即学习“C++免费学习笔记（深入）”；
- 仅多 CPU 竞争（无中断干扰）→ 用
spin_lock()/spin_unlock() - 临界区可能被本 CPU 的硬中断打断 → 必须用
spin_lock_irqsave()+spin_unlock_irqrestore()，否则会死锁 - 临界区调用软中断相关函数（如
tasklet_schedule()）→ 改用spin_lock_bh()/spin_unlock_bh()，避免 softirq 重入
错误示例：在中断 handler 中用 spin_lock() 获取一个也在进程上下文中用 spin_lock_irqsave() 获取的锁，会导致中断 handler 自旋等待自己释放锁（因为中断已被关，但锁未释放）。
semaphore 与 mutex 的选型边界
二者都基于等待队列，但语义和上下文限制完全不同：
-
struct semaphore可用于进程上下文，支持计数（sema_init(&sem, N)），但不能在中断上下文使用；down()可能睡眠，所以调用前必须确保当前处于可调度状态（in_atomic() == false） -
struct mutex是互斥信号量的优化版本，只允许 count=1，且有 fastpath 路径；它禁止在中断上下文、softirq、timer callback 中调用mutex_lock()，否则触发DEBUG_MUTEXES报错 - 驱动 probe 函数中初始化锁时，
mutex_init()和sema_init()都安全；但spin_lock_init()必须在preempt_disable()或中断关闭状态下调用（UP 系统上尤其敏感）
典型误用：read() 系统调用路径中用 down() 等待 DMA 完成，但没检查 current->flags & PF_MEMALLOC，导致内存回收路径中死锁。
嵌套与持有时间的硬约束
自旋锁严禁任何可能导致调度的行为，包括但不限于：
- 调用
copy_to_user()或printk()（后者在某些配置下会触发 console_lock） - 调用含
msleep()、wait_event()、schedule_timeout()的函数 - 递归获取同一把
spinlock_t（内核不提供可重入自旋锁） - 在持有
spinlock_t时再去获取mutex（顺序颠倒易引发 ABBA 死锁）
信号量和互斥体虽允许睡眠，但临界区过长仍会拖慢系统响应 —— 例如在 mutex_lock() 保护的代码里做 memcpy 大缓冲区，应改为先取数据指针、解锁、再拷贝。
最易被忽略的一点：UP 系统上 spin_lock() 实际退化为 preempt_disable()，而 spin_lock_irq() 退化为 local_irq_disable() + preempt_disable()。这意味着在单核调试环境中看似正常的行为，在 SMP 环境下可能暴露出竞态，务必在真实多核平台验证。
