進(jìn)程管理中主調(diào)度器（schedule函數(shù)）中的同步處理

一、前言

本文主要描述了主調(diào)度器（schedule函數(shù)）中的同步處理。

二、進(jìn)程調(diào)度簡(jiǎn)介

進(jìn)程切換有兩種，一種是當(dāng)進(jìn)程由于需要等待某種資源而無法繼續(xù)執(zhí)行下去，這時(shí)候只能是主動(dòng)將自己掛起（調(diào)用schedule函數(shù)），引發(fā)一次任務(wù)調(diào)度過程。另外一種是進(jìn)程被搶占。所謂搶占（preempt）就是在當(dāng)前進(jìn)程歡快執(zhí)行的時(shí)候，終止其對(duì)CPU資源的占用，切換到另外一個(gè)更高優(yōu)先級(jí)的進(jìn)程執(zhí)行。進(jìn)程被搶占往往是由于各種調(diào)度事件的發(fā)生：

1、 時(shí)間片用完

2、 在中斷上下文中喚醒其他優(yōu)先級(jí)更高的進(jìn)程

3、 在其他進(jìn)程上下文中喚醒其他優(yōu)先級(jí)更高的進(jìn)程。

4、 在其他進(jìn)程上下文中修改了其他進(jìn)程的調(diào)度參數(shù)

5、 ……

在當(dāng)前進(jìn)程被搶占的場(chǎng)景下，調(diào)度并不是立刻發(fā)生，而是延遲執(zhí)行，具體的方法是設(shè)定當(dāng)前進(jìn)程的need_resched等于1，然后靜靜的等待最近一個(gè)調(diào)度點(diǎn)的來臨，當(dāng)調(diào)度點(diǎn)到來的時(shí)候，內(nèi)核會(huì)調(diào)用schedule函數(shù)，搶占當(dāng)前task的執(zhí)行。

此外，我們還需要了解基本的搶占控制的知識(shí)。在一個(gè)進(jìn)程的thread info中有一個(gè)preempt_count的成員用來控制搶占，當(dāng)該成員等于0的時(shí)候表示允許搶占，在本文中，我們分別用preempt counter、hardirq counter和softirq counter分別表示其中的bit field。更詳細(xì)的描述可以參考相關(guān)文檔的描述

三、schedule函數(shù)使用了哪些同步機(jī)制

schedule函數(shù)的代碼框架如下：

asmlinkage __visible void __sched schedule(void)?
{?
??? do {?
??????? preempt_disable();－－－－－－－－－－－－－－－－－a

??????????????? raw_spin_lock_irq(&rq->lock);－－－－－－－－b

選擇next task

切到next task執(zhí)行

raw_spin_unlock_irq(&rq->lock);?－－－－－－－c?
??????? sched_preempt_enable_no_resched(); －－－－－－－－d?
??? } while (need_resched()); －－－－－－－－－－－－－－－e?
}

我們以X進(jìn)程切換到Y(jié)進(jìn)程為例，描述schedule函數(shù)中同步機(jī)制的使用情況。在X進(jìn)程上下文中，a點(diǎn)首先關(guān)閉了搶占，X task的preempt counter會(huì)加1。然后在b點(diǎn)會(huì)持有該CPU runqueue的spinlock，當(dāng)然在這個(gè)過程中會(huì)disable CPU中斷處理，同時(shí)將X task的preempt counter再次加1，這時(shí)候X task的preempt counter應(yīng)該等于2。

打開X task的搶占的時(shí)候是在重新調(diào)度X在某個(gè)CPU上執(zhí)行的時(shí)候，這時(shí)候，在上面代碼中的c和d點(diǎn)來遞減preempt counter，當(dāng)進(jìn)入e點(diǎn)的時(shí)候，preempt counter已經(jīng)等于0。

由于在切換過長(zhǎng)設(shè)計(jì)runqueue隊(duì)列的操作，因此需要spin lock來保護(hù)。不過在進(jìn)程切換過程中，runqueue spin lock是不同進(jìn)程來協(xié)同處理的。我們?nèi)匀灰訶進(jìn)程切換到Y(jié)進(jìn)程為例。在X進(jìn)程中，在b點(diǎn)持鎖并disable了本地中斷，而spin lock的釋放是在Y進(jìn)程中完成的（c點(diǎn)），在釋放spin lock的同時(shí)，也會(huì)打開cpu中斷。

四、可不可以禁止搶占的時(shí)候調(diào)用schedule函數(shù)

在進(jìn)程上下文中，下面的調(diào)用序列是否可以呢？

preempt_disable

……schedule……

preempt_enable

無論什么場(chǎng)景，disable preempt然后調(diào)用schedule都是很奇怪的一件事情：本來你已經(jīng)禁止搶占了，但是又顯示的調(diào)用schedule函數(shù)，你這不是精神分裂嗎？schedule函數(shù)怎么處理這個(gè)精神分裂的task呢？在調(diào)用schedule函數(shù)之前，它毫無疑問是期待preempt count等于0的，只有當(dāng)前task的preempt count等于0才說明搶占的合理性。不過在整個(gè)進(jìn)程切換的過程中，首先會(huì)在a點(diǎn)禁止搶占，這樣可以確保CPU和當(dāng)前task之間的關(guān)系不變（cpu不變、current task不變，runqueue不變）。這樣，在a和b之間的對(duì)caller的調(diào)用檢查就比較好開展了，具體如下：

static inline void schedule_debug(struct task_struct *prev)?
{

if (unlikely(in_atomic_preempt_off())) {?
??????? __schedule_bug(prev);?
??????? preempt_count_set(PREEMPT_DISABLED);?
??? }?
}

in_atomic_preempt_off這個(gè)宏就是對(duì)當(dāng)前preempt count進(jìn)行測(cè)試，這時(shí)候正確的preempt counter應(yīng)該是等于1，其他的bit field，例如softirq counter、hardirq count等都是0。具體關(guān)于preempt count的位域描述可以參考本站軟中斷的文檔。如果沒有設(shè)定正確的preempt_count就調(diào)用schedule函數(shù)，那么說明在atomic上下文中錯(cuò)誤的進(jìn)行了調(diào)度，__schedule_bug會(huì)打印出相關(guān)信息，方便調(diào)試。

雖然在錯(cuò)誤的場(chǎng)景中調(diào)用了schedule函數(shù)，但是內(nèi)核還是要艱難前行啊，因此這里會(huì)修改preempt count的值為PREEMPT_DISABLED，而這才是進(jìn)入schedule函數(shù)正確的姿勢(shì)。

五、可不可以關(guān)閉中斷調(diào)用schedule函數(shù)？

在進(jìn)程上下文中，下面的調(diào)用序列是否可以呢？

local_irq_disable

……schedule……

local_irq_enable

當(dāng)然這里也許不是直接調(diào)用schedule函數(shù)，很多內(nèi)核接口API會(huì)隱含調(diào)用schedule函數(shù)，因此也許你會(huì)有意無意的寫出上面形態(tài)的代碼。

首先需要明確一點(diǎn)：從X進(jìn)程切換到Y(jié)進(jìn)程的時(shí)候，如果在X進(jìn)程中關(guān)閉中斷，然后切換到Y(jié)進(jìn)程，如果中斷不恢復(fù)的話，那么Y進(jìn)程會(huì)一直執(zhí)行，直到Y(jié)自己良心發(fā)現(xiàn)，讓出CPU。這當(dāng)然是不被允許的。因此，在調(diào)用schedule進(jìn)行進(jìn)程切換的時(shí)候，無論調(diào)用者是否關(guān)閉中斷，在b點(diǎn)都會(huì)關(guān)閉中斷（注意，這時(shí)候并沒有記錄之前的中斷狀態(tài)）。而在切入到Y(jié)進(jìn)程之后，在c點(diǎn)都會(huì)顯式的打開CPU中斷。因此，上面的代碼雖然不推薦，但是也不會(huì)對(duì)調(diào)度產(chǎn)生太大的影響。

六、禁止中斷是否可以禁止搶占？

禁止了中斷的確等于了禁止搶占，但是并不意味著它們兩個(gè)完全等同，因?yàn)樵趐reempt disable－－－preempt enable這個(gè)的調(diào)用過程中，在打開搶占的時(shí)候有一個(gè)搶占點(diǎn)，內(nèi)核控制路徑會(huì)在這里檢查搶占，如果滿足搶占條件，那么會(huì)立刻調(diào)度schedule函數(shù)進(jìn)行進(jìn)程切換，但是local irq disable－－－local irq enable的調(diào)用中，并沒有顯示的搶占檢查點(diǎn)，當(dāng)然，中斷有點(diǎn)特殊，因?yàn)橐坏┐蜷_中斷，那么pending的中斷會(huì)進(jìn)來，并且在返回中斷點(diǎn)的時(shí)候會(huì)檢查搶占，但是也許下面的這個(gè)場(chǎng)景就無能為力了。進(jìn)程上下文中調(diào)用如下序列：

（1）local irq disable

（2）wake up high level priority task

（3）local irq enable

當(dāng)喚醒的高優(yōu)先級(jí)進(jìn)程被調(diào)度到本CPU執(zhí)行的時(shí)候，按理說這個(gè)高優(yōu)先級(jí)進(jìn)程應(yīng)該立刻搶占當(dāng)前進(jìn)程，但是這個(gè)場(chǎng)景無法做到。在調(diào)用try_to_wake_up的時(shí)候會(huì)設(shè)定need resched flag并檢查搶占，但是由于中斷disable，因此不會(huì)立刻調(diào)用schedule，但是在step （3）的時(shí)候，由于沒有檢查搶占，這時(shí)候本應(yīng)立刻搶占的高優(yōu)先級(jí)進(jìn)程會(huì)發(fā)生嚴(yán)重的調(diào)度延遲.....直到下一個(gè)搶占點(diǎn)到來。