Linux中的spinlock机制[四]

转自：https://zhuanlan.zhihu.com/p/90634198

Linux中的spinlock机制[四] - API的使用

兰新宇

talk is cheap

 

前面文章介绍的spinlock加锁的实现都是基于的arch_spin_lock()这个函数，但内核编程实际使用的通常是spin_lock()，它们中间还隔了好几层调用关系。先来看最外面的一层（代码位于/include/linux/spinlock.h）：

static __always_inline void spin_lock(spinlock_t *lock)
{
    raw_spin_lock(&lock->rlock);
}

#define raw_spin_lock(lock) _raw_spin_lock(lock)

接下来，_raw_spin_lock()的实现将出现分野。

【关闭调度】

• SMP实现

spinlock通常是用于多核系统（SMP）的，但它同样也可以用于单核（UP）的场景。针对SMP，_raw_spin_lock()的实现是这样的（定义在/include/linux/spinlock_api_smp.h）：

#ifdef CONFIG_INLINE_SPIN_LOCK
#define _raw_spin_lock(lock) __raw_spin_lock(lock)
#endif

static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
    preempt_disable();
    ...
    LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}

采用inline函数，可以减少函数调用的开销，提高执行速度，但不利于跟踪调试，所以内核提供了"CONFIG_INLINE_SPIN_LOCK"这个配置选项供用户选择。

越往内层，函数名前面的下划线"_"越多。可以看到，在最内侧的__raw_spin_lock()中，调用了preempt_disable()来关闭调度。也就是说，运行在一个CPU上的代码使用spin_lock()试图加锁之后，基于该CPU的线程调度和抢占就被禁止了，这也体现了spinlock作为"busy loop"形式的锁的语义。

到了do_raw_spin_lock()这一步，就进入了和架构相关的arch_spin_lock()。

static inline void do_raw_spin_lock(raw_spinlock_t *lock)
{
    __acquire(lock);
    arch_spin_lock(&lock->raw_lock);
    ...
}

• UP实现

再来看下_raw_spin_lock()针对UP系统的实现（代码位于/include/linux/spinlock_api_up.h）：

#define _raw_spin_lock(lock)  __LOCK(lock)

#define __LOCK(lock) 
  do { preempt_disable(); ___LOCK(lock); } while (0)

#define ___LOCK(lock) 
  do { __acquire(lock); (void)(lock); } while (0)

在UP的环境中，不再需要防止多个CPU对共享变量的同时访问，所以spin_lock()的作用仅仅是关闭调度，等同于（或者说退化成了）preempt_disable()。

之所以UP系统也支持使用spinlock相关的函数，是因为这样同一套代码可以同时支持UP和SMP的应用，只需要在配置中选择是否使用"CONFIG_SMP"就可以了。

【关闭中断】

spin_lock()可以防止线程调度，但不能防止硬件中断的到来，以及随后的中断处理函数（hardirq）的执行，这会带来什么影响呢？

试想一下，假设一个CPU上的线程T持有了一个spinlock，发生中断后，该CPU转而执行对应的hardirq。如果该hardirq也试图去持有这个spinlock，那么将无法获取成功，导致hardirq无法退出。在hardirq主动退出之前，线程T是无法继续执行以释放spinlock的，最终将导致该CPU上的代码不能继续向前运行，形成死锁（dead lock）。

为了防止这种情况的发生，我们需要使用spin_lock_irq()函数，一个spin_lock()和local_irq_disable()的结合体，它可以在spinlock加锁的同时关闭中断。

因为中断关闭的操作是可以嵌套的，更多的时候我们是使用local_irq_save()来记录关中断的状态，对应地一个更常用的函数就是spin_lock_irqsave()。

static inline unsigned long __raw_spin_lock_irq_save(raw_spinlock_t *lock)
{
    unsigned long flags;
	
    local_irq_save(flags);
    __raw_spin_lock(lock);
    return flags;
}

然而，local_irq_save()只能对本地CPU执行关中断操作，所以即便使用了spin_lock_irqsave()，如果其他CPU上发生了中断，那么这些CPU上的hardirq，也有可能试图去获取一个被本地CPU上运行的线程T占有的spinlock。

不过没有关系，因为此时hardirq和线程T运行在不同的CPU上，等到线程T继续运行释放了这个spinlock，hardirq就有机会获取到，不至于造成死锁。

对于UP系统，spin_lock_irqsave()的作用只剩下关闭中断了（中断关闭时不会产生时钟中断，调度自然也是关闭的），也就退化成了local_irq_save()。

【屏蔽softirq】

如果hardirq不会和线程共享变量，是不是就可以直接使用spin_lock()呢？非也，因为在切回被打断的线程之前，还可能会执行对应的softirq函数。如果该softirq可能访问和线程共享的变量，那么线程就应该使用spin_lock_bh()，一个spin_lock()加local_bh_disable()的二合一函数，否则也可能会导致dead lock。

"bh"代表bottom half，而Linux中的bottom half包括softirq, tasklet和workqueue三种，由于workqueue是运行在进程上下文，所以这里的"bh"只针对softirq和tasklet。

【API的选择】

如果关闭了中断，hardirq不会执行，对应的softirq就更不会执行，可见，使用spin_lock_irqsave()无疑是最安全的，但同时也是开销最大的。

从程序性能的角度出发，在进程上下文中，对于不会和hardirq/softirq共享的变量，应该尽量使用更轻量级的spin_lock()。只会和softirq共享而不会和hardirq共享的，则应该使用spin_lock_bh()。

对于hardirq上下文，因为Linux是不支持hardirq嵌套的（参考这篇文章评论区的讨论），在hardirq执行期间，CPU对中断的响应默认是关闭的，所以可直接使用spin_lock()。

至于softirq上下文，因为有可能被hardirq打断，针对会和hardirq共享的变量，需使用spin_lock_irqsave()。

总之，在用一个锁之前，你得清楚有可能和你竞争这个锁的对手是谁。

至此，就可以解答上文留下的那个问题，即为什么一个CPU在一种context下，至多试图获取（或者说竞争）一个spinlock。线程使用spin_lock()试图获取spinlock A，此时发生了中断，如果hardirq获取spinlock B，那么该CPU就同时在试图获取2个spinlock。

如果hardirq没有试图获取spinlock，执行完后进入了softirq，softirq试图获取spinlock B，然后又被另一个中断打断，新的hardirq在执行过程中又试图获取spinlock C，那么该CPU就同时在试图获取3个spinlock。

如果再加入nmi，以此类推，一个CPU至多同时试图获取4个spinlock。

spin_lock_irqsave()/spin_lock_bh()可以防止hardirq/softirq和线程共享变量造成的死锁，但这只是死锁可能出现的一种情况，也可以说是仅依靠选择合适的API就可以避免的死锁，更多死锁的场景和应对办法，将交由下文讨论。

 

参考：

https://www.kernel.org/doc/htmldocs/kernel-locking/index.html

字节岛 - 自旋锁spin_lock、spin_lock_irq以及spin_lock_irqsave的区别

 

原创文章，转载请注明出处。