進程切換分兩步：

1.切換頁目錄以使用新的地址空間

2.切換內核棧和硬件上下文

對于linux來說，線程和進程的最大區(qū)別就在于地址空間，對于線程切換，第1步是不需要做的，第2是進程和線程切換都要做的。

切換的性能消耗：

1、線程上下文切換和進程上下問切換一個最主要的區(qū)別是線程的切換虛擬內存空間依然是相同的，但是進程切換是不同的。這兩種上下文切換的處理都是通過操作系統(tǒng)內核來完成的。內核的這種切換過程伴隨的最顯著的性能損耗是將寄存器中的內容切換出。

2、另外一個隱藏的損耗是上下文的切換會擾亂處理器的緩存機制。簡單的說，一旦去切換上下文，處理器中所有已經緩存的內存地址一瞬間都作廢了。還有一個顯著的區(qū)別是當你改變虛擬內存空間的時候，處理的頁表緩沖（processor's Translation Lookaside Buffer (TLB)）或者相當的神馬東西會被全部刷新，這將導致內存的訪問在一段時間內相當的低效。但是在線程的切換中，不會出現(xiàn)這個問題。

系統(tǒng)調用：處于進程上下文

系統(tǒng)調用是在進程上下文中,并沒有tasklet之類的延遲運行,系統(tǒng)調用本身可以休眠,這些可以參見內核代碼

雖然系統(tǒng)調用實與其他中斷實現(xiàn)有點類似,通過IDT表查找入口處理函數,但是系統(tǒng)調用與其他中斷最大的不同是,系統(tǒng)調用是代表當前進程執(zhí)行的,所以current宏/task_struct是有意義的,這個休眠可以被喚醒
 
系統(tǒng)調用，異常，中斷（其中中斷是異步時鐘，異常時同步時鐘），也可以把系統(tǒng)調用成為異常

中斷上下文：在中斷中執(zhí)行時依賴的環(huán)境，就是中斷上下文（不包括系統(tǒng)調用，是硬件中斷）

進程上下文：當一個進程在執(zhí)行時,CPU的所有寄存器中的值、進程的狀態(tài)以及堆棧中的內容被稱為該進程的上下文

1、首先，這兩個上下文都處于內核空間。

2、其次，兩者的區(qū)別在于，進程上下文與當前執(zhí)行進程密切相關，而中斷上下文在邏輯上與進程沒有關系。

進程上下文主要是異常處理程序和內核線程。內核之所以進入進程上下文是因為進程自身的一些工作需要在內核中做。例如，系統(tǒng)調用是為當前進程服務的，異常通常是處理進程導致的錯誤狀態(tài)等。所以在進程上下文中引用current是有意義的。

內核進入中斷上下文是因為中斷信號而導致的中斷處理或軟中斷。而中斷信號的發(fā)生是隨機的，中斷處理程序及軟中斷并不能事先預測發(fā)生中斷時當前運行的是哪個進程，所以在中斷上下文中引用current是可以的，但沒有意義。事實上，對于A進程希望等待的中斷信號，可能在B進程執(zhí)行期間發(fā)生。例如，A進程啟動寫磁盤操作，A進程睡眠后現(xiàn)在時B進程在運行，當磁盤寫完后磁盤中斷信號打斷的是B進程，在中斷處理時會喚醒A進程。

上下文這個詞會讓人想到進程的CPU寄存器狀態(tài)，但好像進入進程上下文（異常處理系統(tǒng)調用）和進入中斷上下文（中斷處理），內核所做的工作沒有太大區(qū)別。所以，這兩個上下文的主要區(qū)別，我認為在于是否與進程相關。

運行于進程上下文的內核代碼是可搶占的，但中斷上下文則會一直運行至結束，不會被搶占。因此，內核會限制中斷上下文的工作，不允許其執(zhí)行如下操作：

(1) 進入睡眠狀態(tài)或主動放棄CPU;

由于中斷上下文不屬于任何進程，它與current沒有任何關系（盡管此時current指向被中斷的進程），所以中斷上下文一旦睡眠或者放棄CPU，將無法被喚醒。所以也叫原子上下文（atomic context）。

(2) 占用互斥體;

為了保護中斷句柄臨界區(qū)資源，不能使用mutexes。如果獲得不到信號量，代碼就會睡眠，會產生和上面相同的情況，如果必須使用鎖，則使用spinlock。

(3) 執(zhí)行耗時的任務;

中斷處理應該盡可能快，因為內核要響應大量服務和請求，中斷上下文占用CPU時間太長會嚴重影響系統(tǒng)功能。在中斷處理例程中執(zhí)行耗時任務時，應該交由中斷處理例程底半部來處理。

(4) 訪問用戶空間虛擬內存。

因為中斷上下文是和特定進程無關的，它是內核代表硬件運行在內核空間，所以在中斷上下文無法訪問用戶空間的虛擬地址

(5) 中斷處理例程不應該設置成reentrant（可被并行或遞歸調用的例程）。

因為中斷發(fā)生時，preempt和irq都被disable，直到中斷返回。所以中斷上下文和進程上下文不一樣，中斷處理例程的不同實例，是不允許在SMP上并發(fā)運行的。

(6)中斷處理例程可以被更高級別的IRQ中斷。（不能嵌套中斷）使用軟中斷，上部分關中斷，也就是禁止嵌套，下半部分使用軟中斷

如果想禁止這種中斷，可以將中斷處理例程定義成快速處理例程，相當于告訴CPU，該例程運行時，禁止本地CPU上所有中斷請求。這直接導致的結果是，由于其他中斷被延遲響應，系統(tǒng)性能下降。

軟中斷是一種延時機制，代碼執(zhí)行的優(yōu)先級比進程要高，比硬中斷要低。相比于硬件中斷，軟中段是在開中斷的環(huán)境中執(zhí)行的（長時間關中斷對系統(tǒng)的開銷太大）， 代碼是執(zhí)行在中斷/線程上下文的，是不能睡眠的，雖然每個cpu都有一個對應的ksoftirqd/n線程來執(zhí)行軟中斷，但是do_softirq這個函數也還會在中斷退出時調用到，因此不能睡眠(中斷上下文不能睡眠的原因是由于調度系統(tǒng)是以進程為基本單位的，調度時會把當前進程的上下文保存在task_struct這個數據結構中，當進程被調度重新執(zhí)行時會找到執(zhí)行的斷點，但是中斷上下文是沒有特定task_struct結構體的，當然現(xiàn)在有所謂的線程話中斷，可以滿足在中斷處理函數執(zhí)行阻塞操作，但是實時性可能會有問題。還有就是中斷代表當前進程執(zhí)行的概念，個人感覺有點扯淡，畢竟整個內核空間是由所有進程共享的，不存在代表的概念)

上面我們介紹的可延遲函數運行在中斷上下文中（軟中斷的一個檢查點就是do_IRQ退出的時候），于是導致了一些問題：軟中斷不能睡眠、不能阻塞。由于中斷上下文出于內核態(tài)，沒有進程切換，所以如果軟中斷一旦睡眠或者阻塞，將無法退出這種狀態(tài)，導致內核會整個僵死。但可阻塞函數不能用在中斷上下文中實現(xiàn)，必須要運行在進程上下文中，例如訪問磁盤數據塊的函數。因此，可阻塞函數不能用軟中斷來實現(xiàn)。但是它們往往又具有可延遲的特性。

以上就是小編為大家?guī)淼膌inux線程切換和進程切換的方法全部內容了，希望大家多多支持腳本之家~

最新評論