進程上下文和中斷上下文、原子上下文的區別

　　內核空間和用戶空間是現代操做系統的兩種工做模式，內核模塊運行在內核空間，而 用戶態應用程序運行在用戶空間。它們表明不一樣的級別，而對系統資源具備不一樣的訪問權限。內核模塊運行在最高級別（內核態），這個級下全部的操做都受系統信 任，而應用程序運行在較低級別（用戶態）。在這個級別，處理器控制着對硬件的直接訪問以及對內存的非受權訪問。內核態和用戶態有本身的內存映射，即本身的 地址空間。

　　系統的兩種不一樣於行狀態，纔有了上下文的概念。用戶空間的應用程序，若是想請求系統服務，好比操做某個物理設備，映射設備的地址到用戶空間，必須經過系統調用來實現。（系統調用是操做系統提供給用戶空間的接口函數）。以下圖所示：

 

　　經過系統調用，用戶空間的應用程序就會進入內核空間，由內核表明該進程運行於內核空間，這就涉及到上下文的切換，用戶空間和內核空間具備不一樣的 地址映射，通用或專用的寄存器組，而用戶空間的進程要傳遞不少變量、參數給內核，內核也要保存用戶進程的一些寄存器、變量等，以便系統調用結束後回到用戶 空間繼續執行，所謂的進程上下文，就是一個進程在執行的時候，CPU的全部寄存器中的值、進程的狀態以及堆棧上的內容，當內核須要切換到另外一個進程時，它 須要保存當前進程的全部狀態，即保存當前進程的進程上下文，以便再次執行該進程時，可以恢復切換時的狀態，繼續執行。

　　同理，硬件經過觸發信號，向CPU發送中斷信號，致使內核調用中斷處理程序，進入內核空間。這個過程當中，硬件的一些變量和參數也要傳遞給內核， 內核經過這些參數進行中斷處理，中斷上下文就能夠理解爲硬件傳遞過來的這些參數和內核須要保存的一些環境，主要是被中斷的進程的環境。

　　Linux內核工做在進程上下文或者中斷上下文。提供系統調用服務的內核代碼表明發起系統調用的應用程序運行在進程上下文；另外一方面，中斷處理程序，異步運行在中斷上下文。中斷上下文和特定進程無關。

　　運行在進程上下文的內核代碼是能夠被搶佔的（Linux2.6支持搶佔）。可是一箇中斷上下文，一般都會始終佔有CPU（固然中斷能夠嵌套，但咱們通常不這樣作），不能夠被打斷。正由於如此，運行在中斷上下文的代碼就要受一些限制，不能作下面的事情：

1. 睡眠或者放棄CPU。

　　因爲中斷上下文不屬於任何進程，它與current沒有任何關係（儘管此時current指向被中斷的進程），因此中斷上下文一旦睡眠或者放棄CPU，將沒法被喚醒。因此也叫原子上下文（atomic context）。

2. 嘗試得到信號量

　　爲了保護中斷句柄臨界區資源，不能使用mutexes。若是得到不到信號量，代碼就會睡眠，會產生和上面相同的狀況，若是必須使用鎖，則使用spinlock。

3. 執行耗時的任務

　　中斷處理應該儘量快，由於內核要響應大量服務和請求，中斷上下文佔用CPU時間太長會嚴重影響系統功能。在中斷處理例程中執行耗時任務時，應該交由中斷處理例程底半部來處理。

4. 訪問用戶空間的虛擬地址

　　由於中斷上下文是和特定進程無關的，它是內核表明硬件運行在內核空間，因此在終端上下文沒法訪問用戶空間的虛擬地址

5. 中斷處理例程不該該設置成reentrant（可被並行或遞歸調用的例程）。由於中斷髮生時，preempt和irq都被disable，直到中斷返回。因此中斷上下文和進程上下文不同，中斷處理例程的不一樣實例，是不容許在SMP上併發運行的。

6. 中斷處理例程能夠被更高級別的IRQ中斷。若是想禁止這種中斷，能夠將中斷處理例程定義成快速處理例程，至關於告訴CPU，該例程運行時，禁止本地CPU上全部中斷請求。這直接致使的結果是，因爲其餘中斷被延遲響應，系統性能降低。

內核的一個基本原則就是：在中斷或者說原子上下文中，內核不能訪問用戶空間，並且內核是不能 睡眠的。也就是說在這種狀況下，內核是不能調用有可能引發睡眠的任何函數。通常來說原子上下文指的是在中斷或軟中斷中，以及在持有自旋鎖的時候。內核提供 了四個宏來判斷是否處於這幾種狀況裏：

#define in_irq()     (hardirq_count()) //在處理硬中斷中
#define in_softirq()     (softirq_count()) //在處理軟中斷中
#define in_interrupt()   (irq_count()) //在處理硬中斷或軟中斷中
#define in_atomic()     ((preempt_count() & ~PREEMPT_ACTIVE) != 0) //包含以上全部狀況

這四個宏所訪問的count都是thread_info->preempt_count。這個變量實際上是一個位掩碼。最低8位表示搶佔計數，一般由spin_lock/spin_unlock修改，或程序員強制修改，同時代表內核允許的最大搶佔深度是256。8－15位表示軟中斷計數，一般由local_bh_disable/local_bh_enable修改，同時代表內核允許的最大軟中斷深度是256。位16－27是硬中斷計數，一般由enter_irq/exit_irq修改，同時代表內核允許的最大硬中斷深度是4096。第28位是PREEMPT_ACTIVE標誌。用代碼表示就是：PREEMPT_MASK: 0x000000ffSOFTIRQ_MASK: 0x0000ff00HARDIRQ_MASK: 0x0fff0000凡是上面4個宏返回1獲得地方都是原子上下文，是不允許內核訪問用戶空間，不允許內核睡眠的，不允許調用任何可能引發睡眠的函數。並且表明thread_info->preempt_count不是0，這就告訴內核，在這裏面搶佔被禁用。但 是，對於in_atomic()來講，在啓用搶佔的狀況下，它工做的很好，能夠告訴內核目前是否持有自旋鎖，是否禁用搶佔等。可是，在沒有啓用搶佔的狀況 下，spin_lock根本不修改preempt_count，因此即便內核調用了spin_lock，持有了自旋鎖，in_atomic()仍然會返回 0，錯誤的告訴內核目前在非原子上下文中。因此凡是依賴in_atomic()來判斷是否在原子上下文的代碼，在禁搶佔的狀況下都是有問題的。