linux 内核 --- 临界区关抢占/关中断的区别

 

preempt_disable()
local_irq_disable()/local_irq_save(flags)
spin_lock()
spin_lock_irq()/spin_lock_irqsave(lock, flags)

spin_lock()会调用preempt_disable() 导致本核的抢占调度被关闭（preempt_disable函数实际增加preempt_count来达到此效果），spin_lock_irq()是local_irq_disable()+preempt_disable()的合体。

 

local_irq_disable()/local_irq_save()的disable和save版的唯一区别是，要不要保存CPU对中断的屏蔽状态。

spin_lock_irq()/spin_lock_irqsave(lock, flags)的唯一区别是，要不要保存CPU对中断的屏蔽状态。

 

Kernel的代码明确显示，执行抢占调度的时候，会同时检测“non-zero preempt_count or interrupts are disabled”：

asmlinkage __visible void __sched notrace preempt_schedule(void)
{
    /*
     * If there is a non-zero preempt_count or interrupts are disabled,
     * we do not want to preempt the current task. Just return..
     */
    if (likely(!preemptible()))
        return;

    preempt_schedule_common();
}

#define preemptible()   (preempt_count() == 0 && !irqs_disabled())

 

static __always_inline int preempt_count(void)

{

    return READ_ONCE(current_thread_info()->preempt_count);

}

 

 对于ARM处理器而言，判断irqs_disabled()，其实就是判断CPSR中的IRQMASK_I_BIT是否被设置。

最开始列出的所有函数，都能关闭本核的抢占调度。因为，无论是preempt_count计数状态，还是中断被关闭，都会导致kernel认为无法抢占！

 

既然都关闭了抢占，那么区别在哪里呢？

我们看两段代码，假设下面的代码都发生在NICE为0的普通进程：

preempt_disable()

xxx(1)

preempt_enable()

和

local_irq_disable()

xxx(2)

local_irq_enable()

首先，xxx(1)和xxx(2)里面，都是不可以抢占的。一个搞定了preempt_count，一个搞定了中断。

但是假设xxx(1)内唤醒了一个高优先级的RT任务，那么在preempt_enable()的时刻，直接就是一个抢占点，这个时候，发生schedule，高优先级RT任务进来跑；假设xxx(2)内唤醒了一个高优先级的RT任务，那么在local_irq_enable()的时刻，不是一个抢占点，高优先级RT的任务必须等待下一个抢占点。下一个抢占点，可能是时钟tick处理返回、中断返回、软中断结束、yield()等等多种情况。

在preempt_enable()中，会执行一次preempt_schedule()：

#define preempt_enable() \
do { \
    barrier(); \
    if (unlikely(preempt_count_dec_and_test())) \
        __preempt_schedule(); \
} while (0)

#define __preempt_schedule() preempt_schedule()

 

而local_irq_enable()只是单纯的开启CPU对中断的响应，对于ARM而言，它就是：

#define arch_local_irq_enable arch_local_irq_enable
static inline void arch_local_irq_enable(void)
{
    asm volatile(
        "    cpsie i            @ arch_local_irq_enable"
        :
        :
        : "memory", "cc");
}

再来看大boss，spin_lock_irq是同时调用了preempt_disable和local_irq_disable：

static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)
{
    local_irq_disable();
    preempt_disable();
    spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
    LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}

而对应的spin_unlock_irq()则同时调用了local_irq_enable()和preempt_enable():

static inline void __raw_spin_unlock_irq(raw_spinlock_t *lock)
{
    spin_release(&lock->dep_map, _RET_IP_);
    do_raw_spin_unlock(lock);
    local_irq_enable();
    preempt_enable();
}

为何preempt_enable()比local_irq_enable()后发生呢？如果代码顺序是这样的：

preempt_enable()

local_irq_enable()

 

第一句preempt_enable()想执行抢占调度的话，即便调用了preempt_schedule()，但是由于IRQ还是关门的，preempt_schedule()函数会立即返回，所以无法抢占；后一句local_irq_enable()不会执行抢占调度。所以，如果这么干的话，

spin_lock_irq()

xxx(3)

spin_unlock_irq()

 

如果xxx(3)唤醒了高优先级的RT，在spin_unlock_irq()的时刻，将无法直接抢占！

还好，真正的顺序是：

local_irq_enable()

preempt_enable()

 

所以，在spin_unlock_irq()的时刻，RT进程就换入执行了。

看小一点的boss，spin_lock()：

spin_lock()

xxx(4)

spin_unlock()

 

如果xxx(4)唤醒了RT进程，在spin_unlock()的时刻，会立即抢入。因为spin_unlock()会调用preempt_enable()。

 

而抢占又杀了谁？

理论上，关抢占，并没有彻底的关闭调度器，因为进程还是可以主动地sleep：

 

上述代码，在spin_lock的区间里面，调用了msleep()，这个时候，不属于抢占，Linux还是会pick下一个task来跑

不过这样的代码，一般在后期蕴藏着巨大的风险，导致后期的莫名崩溃。所以呢，实际的工程里面，我们是严格地禁止的。

 

建议大家打开Kernel里面的config里面的DEBUG_ATOMIC_SLEEP，一旦出现这种情况，让kernel去汇报错误。

这种情况下，kernel检测到有人在atomic上下文里面执行可能睡眠的行为，会直接报执行的栈回溯。