<!-- p { margin-bottom: 0.08in; } -->

當進程等待資源或者事件時，就進入睡眠狀態(tài)。有兩種睡眠態(tài)，不可中斷睡眠態(tài)（ TASK_UNINTERRUPTIBLE ）和可中斷睡眠態(tài)（ TASK_INTERRUPTIBLE ）。

處于可中斷睡眠態(tài)的進程不光可以由 wake_up 直接喚醒，還可以由信號喚醒。在 schedule() 函數(shù)中，會把處于可中斷睡眠態(tài)并且收到信號的進程變成運行態(tài)，使他參與調(diào)度選擇。 Linux0.11 中進入可中斷睡眠狀態(tài)的方法有 3 中

1. 調(diào)用 interruptible_sleep_on() 函數(shù)

2. 調(diào)用 sys_pause() 函數(shù)

3. 調(diào)用 sys_waitpid() 函數(shù)。

第一種情況用于等待外設資源時（如等待 I/O 設備），這時當前進程會掛在對應的等待隊列上。第二第三種情況用于事件，即等待信號。

進程要進入不可中斷睡眠態(tài)，只能通過 sleep_on() 函數(shù)。要使處于不可中斷睡眠態(tài)的進程進入運行態(tài)，只能由其他進程調(diào)用 wake_up() 將它喚醒。當進程等待系統(tǒng)資源（比如高速緩沖塊，文件 i 節(jié)點或者文件系統(tǒng)的超級塊）時，會調(diào)用 sleep_on() 函數(shù)，使當前進程掛起在相關資源的等待隊列上。

這部分代碼很短，一共三個函數(shù) sleep_on() ， wake_up() 和 interruptible_sleep_on() 。在 sched.c 中。但是代碼比較難理解，因為構造的等待隊列是一個隱式隊列，利用進程地址空間的獨立性隱式地連接成一個隊列。這個想法很奇妙。

<!-- p { margin-bottom: 0.08in; } -->

sleep_on()

/****************************************************************************/ /* 功能：當前進程進入不可中斷睡眠態(tài)，掛起在等待隊列上 */ /* 參數(shù)：p 等待隊列頭 */ /* 返回：（無） */ /****************************************************************************/ void sleep_on(struct task_struct **p) { struct task_struct *tmp; // tmp用來指向等待隊列上的下一個進程 if (!p) // 無效指針，退出 return; if (current == &(init_task.task)) // 進程0不能睡眠 panic("task[0] trying to sleep"); tmp = *p; // 下面兩句把當前進程放到等待隊列頭，等待隊列是以堆棧方式 *p = current; // 管理的。后到的進程等在前面 current->state = TASK_UNINTERRUPTIBLE; // 進程進入不可中斷睡眠狀態(tài) schedule(); // 進程放棄CPU使用權，重新調(diào)度進程 // 當前進程被wake_up()喚醒后，從這里開始運行。 // 既然等待的資源可以用了，就應該喚醒等待隊列上的所有進程，讓它們再次爭奪 // 資源的使用權。這里讓隊列里的下一個進程也進入運行態(tài)。這樣當這個進程運行 // 時，它又會喚醒下下個進程。最終喚醒所有進程。 if (tmp) tmp->state=0; }

<!-- p { margin-bottom: 0.08in; } -->

這個函數(shù)牽涉到 3 個指針， p ， tmp 和 current 。

p 是指向指針的指針，實際上 *p 指向的是等待隊列頭。系統(tǒng)資源（高速緩沖塊，文件 i 節(jié)點或者文件系統(tǒng)的超級塊）的數(shù)據(jù)結構中都一個 struct task_struct * 類型的指針，指向的就是等待該資源的進程隊列頭。比如 i 節(jié)點中的 i_wait ，高速緩沖塊中的 b_wait ，超級塊中的 s_wait 。 *p 對于等待隊列上的所有進程都是一樣的。

current 指向的是當前進程指針，是全局變量。

tmp 位于當前進程的地址空間內(nèi)，是局部變量。不同的進程有不同 tmp 變量。等待隊列就是利用這個變量把所有等待同一個資源的進程連接起來。具體的說，所有等待在隊列上的進程，都是在 sleep_on() 中 schedule() 中被切換出去的，這些進程還停留在 sleep_on() 函數(shù)中，在函數(shù)的堆棧空間里面，存放了局部變量 tmp 。

假如當前進程要進入某個高速緩沖塊的等待隊列，而且該等待隊列上已經(jīng)有另外兩個進程 task1 和 task2 先后進入。形成的隊列如圖。等待隊列是堆棧式的，先進入隊列的進程排在最后。

<!-- p { margin-bottom: 0.08in; } -->

在調(diào)用了 sleep_on() 的地方，我們可以發(fā)現(xiàn) sleep_on() 往往是放在一個循環(huán)中的（比如 wait_on_buffer() ， wait_on_inode() ， lock_inode() ， lock_super() ， wait_on_super() 等函數(shù)）。當進程從 sleep_on() 返回時，并不能保證當前進程取得了資源使用權，因為調(diào)用 wake_up() 進程切換到從 sleep_on() 中蘇醒的過程中，發(fā)生了進程調(diào)度，中間很可能有別的進程取得了資源。

wake_up()

/****************************************************************************/ /* 功能：喚醒等待隊列上的頭一個進程 */ /* 參數(shù)：p 等待隊列頭 */ /* 返回：（無） */ /****************************************************************************/ void wake_up(struct task_struct **p) { if (p && *p) { (**p).state=0; // 把隊列上的第一個進程設為運行態(tài) *p=NULL; // 把隊列頭指針清空，這樣失去了都其他等待進程的跟蹤。 // 一般情況下這些進程遲早會得到運行。 } }

<!-- p { margin-bottom: 0.08in; } --> <!-- p { margin-bottom: 0.08in; } -->

下面分析 sleep_on() 和 wait_up() 配合使用的情況

情況一 游離隊列的產(chǎn)生

先分析一下 sleep_on() 和 wake_up() 在通常情況下的工作原理。考慮一個非常簡單的情況，假設目前系統(tǒng)只有 3 個進程，且都等在隊列上，隊列的頭指針設為 wait 。

<!-- p { margin-bottom: 0.08in; } -->

然后系統(tǒng)資源得到釋放，當前進程調(diào)用 wake_up(wait) 。這時 Task C 變成了運行態(tài)。

<!-- p { margin-bottom: 0.08in; } -->

之后進程調(diào)度發(fā)生， Task C 被選中，開始運行。 Task C 是從 sheep_on() 中的 schedule() 的后一條語句開始運行，它把 Task B 的狀態(tài)變成運行態(tài)。隨后 Task C 退出 sheep_on() 函數(shù)，堆棧中的局部變量 tmp 消失，這樣再沒有指向 Task B 的指針， Task B 開頭的隊列游離了。

<!-- p { margin-bottom: 0.08in; } -->

情況 1-1

這時對同一個資源有兩個進程是可運行狀態(tài)，但是當前進程是 Task C ，只要它不調(diào)用 schedule ，它是不會被搶斷的。因此 Task C 繼續(xù)運行，取得了它想要的資源，這時 Task C 可以完成它的任務了。當進程調(diào)度再次發(fā)生時， Task B 會被選中，同樣， Task B 會把 Task A 變成可運行態(tài)，而它自己得到了資源。最終 Task A 也會得到執(zhí)行。這樣，等待在一個資源上的三個任務最終都得到運行。

情況 1-2

假設 Task C 在得到資源后，又主動調(diào)用了 schedule() ，進程調(diào)度程序這時選中了 Task B 。 Task B 從上次中斷的地方開始運行，即從 sleep_on() 中 schedule() 后面的語句開始運行。它會把 Task A 也變成可運行狀態(tài)。然后退出 sleep_on() ， tmp 變量消失。但是不幸的是它發(fā)現(xiàn)資源仍然被占用，所以再次進入睡眠，又連接到 wait 隊列上了。

<!-- p { margin-bottom: 0.08in; } -->

從這個情況可以看到，雖然系統(tǒng)運行過程中，可能會把等待隊列切分成很多游離隊列，但是這些隊列頭上的進程都是運行態(tài)，這保證 schedule() 函數(shù)最終還是會找到它。

情況二 游離隊列的合并

假設目前進程等待資源的情況如下，某個進程占用資源不放，導致有 7 個進程等待該資源。產(chǎn)生 3 個隊列，其中兩個游離。

<!-- p { margin-bottom: 0.08in; } -->

這時調(diào)度函數(shù)選中 Task E 執(zhí)行， Task E 先喚醒 Task D 但發(fā)現(xiàn)資源不能用，再次睡眠，把自己移到 wait 隊列，脫離了游離隊列。調(diào)度再次發(fā)生。

<!-- p { margin-bottom: 0.08in; } -->

假如這時 Task B 得到運行，同樣 Task B 也只能喚醒 Task A ，而把自己移動到等待隊列

p { margin-bottom: 0.08in; }

這樣，只要游離隊列頭上的進程是運行態(tài)，游離隊列可以再次合并到原先的等待隊列上。

p { margin-bottom: 0.08in; }

interruptible_sleep_on()

/****************************************************************************/ /* 功能：當前進程進入可中斷睡眠態(tài)，掛起在等待隊列上 */ /* 參數(shù)：p 等待隊列頭 */ /* 返回：（無） */ /****************************************************************************/ void interruptible_sleep_on(struct task_struct **p) { struct task_struct *tmp; // tmp用來指向等待隊列上的下一個進程 if (!p) // 無效指針，退出 return; if (current == &(init_task.task)) // 進程0不能睡眠 panic("task[0] trying to sleep"); tmp=*p; // 和sleep_on()一樣，構建隱式隊列 *p=current; repeat: current->state = TASK_INTERRUPTIBLE; // 當前進程狀態(tài)變成可中斷睡眠態(tài) schedule(); // 重新調(diào)度進程 // 當進程蘇醒后，從這里繼續(xù)運行 if (*p && *p != current) { // 如果當前進程之前還有進程，這把頭進程喚醒， (**p).state=0; // 自己進入睡眠態(tài)。這樣做為了保證隊列棧式管理 goto repeat; } *p=NULL; // 和wake_up()一樣 if (tmp) // 產(chǎn)生了游離隊列，需要把頭進程喚醒 tmp->state=0; }

Linux0.11內(nèi)核--進程的調(diào)度(運行態(tài)(就緒態(tài))和睡眠態(tài)之間的轉換)