内核自旋锁spin_lock

本文详细介绍了自旋锁的概念及其在Linux内核中的应用。包括自旋锁的基本原理、不同类型的自旋锁(如spin_lock、spin_lock_irq和spin_lock_irqsave)的实现方式及其适用场景。同时探讨了自旋锁在内核中的作用机制,如何防止死锁等问题。

自旋锁的初衷:在短期间内进行轻量级的锁定。一个被争用的自旋锁使得请求它的线程在等待锁重新可用的期间进行自旋(特别浪费处理器时间),所以自旋锁不应该被持有时间过长。如果需要长时间锁定的话, 最好使用信号量。

单处理器的自旋锁

  • 首先,自旋锁的目的如果在系统不支持内核抢占时,自旋锁的实现也是空的,因为单核只有一个线程在执行,不会有内核抢占,从而资源也不会被其他线程访问到。
  • 其次,支持内核抢占,由于自旋锁是禁止抢占内核的,所以不会有其他的进程因为等待锁而自旋.
  • 最后,只有在多cpu下,其他的cpu因为等待该cpu释放锁,而处于自旋状态,不停轮询锁的状态。所以这样的话,如果一旦自旋锁内代码执行时间较长,等待该锁的cpu会耗费大量资源,也是不同于信号量和互斥锁的地方。

简单来说,自旋锁在内核中主要用来防止多处理器中并发访问临界区,防止内核抢占造成的竞争。

自旋锁内睡眠禁止睡眠问题:如果自旋锁锁住以后进入睡眠,而此时又不能进行处理器抢占(锁住会disable prempt),其他进程无法获得cpu,这样也不能唤醒睡眠的自旋锁,因此不相应任何操作。

自旋锁为什么广泛用于内核:自旋锁是一种轻量级的互斥锁,可以更高效的对互斥资源进行保护。自旋锁本来就只是一个很简单的同步机制,在SMP之前根本就没这个东西,一切都是Event之类的同步机制,这类同步机制都有一个共性就是:一旦资源被占用都会产生任务切换,任务切换涉及很多东西的(保存原来的上下文,按调度算法选择新的任务,恢复新任务的上下文,还有就是要修改cr3寄存器会导致cache失效)这些都是需要大量时间的,因此用Event之类来同步一旦涉及到阻塞代价是十分昂贵的,而自旋锁的效率就远高于互斥锁。

 

在Linux内核中何时使用spin_lock,何时使用spin_lock_irqsave很容易混淆。首先看一下代码是如何实现的。

  • spin_lock

   spin_lock  ----->  raw_spin_lock 

1 static inline void __raw_spin_lock(raw_spinlock_t *lock)  
2 {  
3         preempt_disable();  
4         spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);  
5         LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);  
6 }   

1. 只禁止内核抢占,不会关闭本地中断

2. 为何需要关闭内核抢占:假如进程A获得spin_lock->进程B抢占进程A->进程B尝试获取spin_lock->由于进程B优先级比进程A高,先于A运行,而进程B又需要A unlock才得以运行,这样死锁。所以这里需要关闭抢占。 这个原理RTOS的mutex/semaphore是否相同

  a. 因为ThreadX的semaphore,假如进程B获取sema失败,会一直等待,直到A进程释放,不会死锁。 

  b. Mutex: mutex获取一旦失败,进程会进入sleep,直到其他进程释放;而spin_lock则不同,会一直轮训访问,且直到时间片耗完。

  • spin_lock_irq

    spin_lock_irq------> raw_spin_lock_irq

复制代码
1 static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)  
2 {  
3         local_irq_disable();  
4         preempt_disable();  
5         spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);  
6         LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);  
7 }  
复制代码

1. 禁止内核抢占,且关闭本地中断

2. 那么在spin_lock中关闭了内核抢占,不关闭中断会出现什么情况呢?假如中断中也想获得这个锁,会出现和spin_lock中举得例子相同。所以这个时候,在进程A获取lock之后,使用spin_lock_irq将中断禁止,就不会出现死锁的情况

3. 在任何情况下使用spin_lock_irq都是安全的。因为它既禁止本地中断,又禁止内核抢占。

4. spin_lock比spin_lock_irq速度快,但是它并不是任何情况下都是安全的。

  • spin_lock_irqsave

  spin_lock_irqsave------>__raw_spin_lock_irqsave

复制代码
 1 static inline unsigned long __raw_spin_lock_irqsave(raw_spinlock_t *lock)
 2 {
 3     unsigned long flags;
 4 
 5     local_irq_save(flags);
 6     preempt_disable();
 7     spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
 8     /*
 9      * On lockdep we dont want the hand-coded irq-enable of
10      * do_raw_spin_lock_flags() code, because lockdep assumes
11      * that interrupts are not re-enabled during lock-acquire:
12      */
13 #ifdef CONFIG_LOCKDEP
14     LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
15 #else
16     do_raw_spin_lock_flags(lock, &flags);
17 #endif
18     return flags;
19 }
复制代码

 

1. 禁止内核抢占,关闭中断,保存中断状态寄存器的标志位

2. spin_lock_irqsave在锁返回时,之前开的中断,之后也是开的;之前关,之后也是关。但是spin_lock_irq则不管之前的开还是关,返回时都是开的(?)

3. spin_lock_irq在自旋的时候,不会保存当前的中断标志寄存器,只会在自旋结束后,将之前的中断打开。

1. spin_lock/spin_unlock:

进程A中调用了spin_lock(&lock)然后进入临界区,此时来了一个中断(interrupt),该中断也运行在和进程A相同的CPU上,并且在该中断处理程序中恰巧也会spin_lock(&lock), 试图获取同一个锁。由于是在同一个CPU上被中断,进程A会被设置为TASK_INTERRUPT状态,中断处理程序无法获得锁,会不停的忙等,由于进程A被设置为中断状态,schedule()进程调度就无法再调度进程A运行,这样就导致了死锁!

但是如果该中断处理程序运行在不同的CPU上就不会触发死锁。 因为在不同的CPU上出现中断不会导致进程A的状态被设为TASK_INTERRUPT,只是换出。当中断处理程序忙等被换出后,进程A还是有机会获得CPU,执行并退出临界区。所以在使用spin_lock时要明确知道该锁不会在中断处理程序中使用

2. spin_lock_irq/spin_unlock_irq

spin_lock_irq----->raw_spin_lock_irq

spin_lock_irq 和 spin_unlock_irq, 如果你确定在获取锁之前本地中断是开启的,那么就不需要保存中断状态,解锁的时候直接将本地中断启用就可以啦

3. spin_lock_irqsave/spin_unlock_irqrestore

使用spin_lock_irqsave在于你不期望在离开临界区后,改变中断的开启/关闭状态!进入临界区是关闭的,离开后它同样应该是关闭的!

如果自旋锁在中断处理函数中被用到,那么在获取该锁之前需要关闭本地中断,spin_lock_irqsave 只是下列动作的一个便利接口:
1 保存本地中断状态(这里的本地即当前的cpu的所有中断)
2 关闭本地中断
3 获取自旋锁
解锁时通过 spin_unlock_irqrestore完成释放锁、恢复本地中断到之前的状态等工作

 

参考微博

1. 什么情况下使用什么样的自旋锁:http://blog.youkuaiyun.com/wesleyluo/article/details/8807919

2. 本地中断概念的理解:http://blog.youkuaiyun.com/adaptiver/article/details/6177646

3. 深入理解自旋锁:http://blog.youkuaiyun.com/vividonly/article/details/6594195

4. 自旋锁和互斥量区别:http://blog.youkuaiyun.com/kyokowl/article/details/6294341

5. 自旋锁的临界区本地cpu不会发生任何进程调度:http://blog.chinaunix.net/uid-23769728-id-3367773.html

总结

1. 这样是否可以这么说,spin_lock为了防止内核的抢占死锁,spin_lock_irq为了防止内核和中断的抢占死锁,spin_lock_irqsave为了防止进入自旋状态丢掉之前的中断状态。

### **自旋锁spin_lock)在用户空间是否可用?** #### **1. 核心结论** **默认情况下,Linux 内核的 `spin_lock` 不能在用户空间直接使用!** - **原因**: - 自旋锁是 **内核级同步原语**,依赖内核提供的原子操作和调度机制(如禁用抢占、中断处理)。 - 用户空间没有权限执行内核原子指令(如 `xchg`、`cmpxchg`)。 - 若在用户空间自旋,可能引发 **死锁**(如线程持有锁时被抢占,其他线程无法获取CPU)。 --- #### **2. 用户空间的替代方案** 若需类似自旋锁的行为,可使用以下机制: | **机制** | **特点** | **适用场景** | |-----------------------|-------------------------------------------------------------------------|----------------------------------| | **`pthread_spinlock_t`** | POSIX 提供的用户态自旋锁,通过 `pthread_spin_init`/`pthread_spin_lock` 调用 | 低延迟、短期锁竞争(如高性能计算) | | **原子操作(`atomic_t`)** | 基于 CPU 原子指令(如 `__atomic_add_fetch`),配合忙等待实现轻量同步 | 极简场景(如计数器) | | **互斥锁(`pthread_mutex_t`)** | 阻塞式锁,线程竞争时会休眠 | 通用场景(默认选择) | --- #### **3. 为什么内核自旋锁spin_lock)不能用于用户空间?** - **硬件依赖**: 内核自旋锁通过 `ldrex`/`strex`(ARM)或 `xchg`(x86)等 **特权指令** 实现原子操作,用户态程序无权调用。 - **调度风险**: 用户态线程若自旋时间过长,可能被调度器抢占,导致其他线程无法获取CPU(而内核自旋锁会禁用抢占)。 - **优先级反转**: 用户态自旋可能引发优先级反转问题(内核自旋锁通过 `raw_spin_lock` 等机制避免)。 --- #### **4. 用户态自旋锁示例(`pthread_spinlock_t`)** ```c #include <pthread.h> pthread_spinlock_t spinlock; void* thread_func(void* arg) { pthread_spin_lock(&spinlock); // 自旋等待 // 临界区操作 pthread_spin_unlock(&spinlock); return NULL; } int main() { pthread_spin_init(&spinlock, PTHREAD_PROCESS_PRIVATE); // 初始化 pthread_t thread; pthread_create(&thread, NULL, thread_func, NULL); pthread_join(thread, NULL); pthread_spin_destroy(&spinlock); // 销毁 return 0; } ``` --- #### **5. 何时选择用户态自旋锁?** - **适用场景**: - 临界区极短(纳秒级操作),且线程竞争较少。 - 需要避免线程休眠/唤醒的开销(如实时系统)。 - **不适用场景**: - 临界区较长(可能导致CPU空转浪费)。 - 高并发竞争(改用互斥锁更高效)。 --- #### **6. 性能对比(自旋锁 vs 互斥锁)** | **锁类型** | **线程竞争时的行为** | **开销** | **适用场景** | |------------------|--------------------------|-------------------|--------------------------| | 用户态自旋锁 | CPU 忙等待 | 极低(无上下文切换) | 极短临界区、低竞争 | | 互斥锁(`mutex`) | 线程休眠,触发调度器介入 | 较高(上下文切换) | 通用场景、长临界区 | ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值