系統調用是否在整個軟件中斷處理程序中執行？

Question

系統調用是否在整個軟件中斷處理程序的環境中執行？

我的意思是，像read（）這樣的系統調用可能需要很長時間才能返回，這與ISR執行時間非常短的策略相反。系統調用是否被卸載到其他線程？這是如何運作的？

[A引用任何內核精]

Answer 1

系統調用在ISR中的大多數內核上運行。快速瀏覽一下以前的Linux版本，你會注意到調用內核的int $Ox80。從內核開發的角度來看，這種解決方案可能是最簡單的，它有一個很大的缺點：只要運行ISR;中斷被禁用。禁用中斷太長時間會很糟糕，因爲很顯然你的系統不會被動（它會延遲外部事件，它不會按時重新安排，...）。

搶佔，正如Adel在他的answer中解釋的，這是一個聰明的解決方案。但是，無論內核何時因爲不可用的資源而選擇搶佔線程，它通常都會在禁用中斷的情況下花費大量時間。

在系統調用卸載到其他線程？

你說得對。 Interrupt-threads和/或線程內核是通過更明智的溶液。像Solaris和Mac OS X這樣的內核傾向於擁有非常簡單的ISR，它們只是喚醒高優先級的中斷線程。因此，ISR被減少到最小程度，系統在禁止中斷的情況下運行的時間大大減少。因爲這些中斷線程具有高優先級，所以它們很可能在ISR返回時運行。好的是中斷將再次啓用，因此更高優先級的工作不會被延遲。使用線程內核（如Linux在其最新版本中），可以在內核中完成多項任務，儘管有一個塊，但其他進程仍然能夠進入內核。

希望得到這個幫助！

Answer 2

請閱讀的系統調用是如何工作正常此引用的文字：

系統調用處理程序獲得控制權在用戶程序啓動 系統呼叫。系統調用處理程序將保護域 從主叫用戶保護域更改爲系統調用保護 域，內核，並切換到受保護的堆棧。

系統調用處理程序然後調用支持系統 調用的函數。加載程序爲此目的維護一個當前定義的系統調用表。

系統調用在調用進程中運行，但比調用進程具有更多 權限。這是因爲保護 域已從用戶更改爲內核。

當系統調用函數 執行其操作時，系統調用函數返回到系統調用處理函數。系統調用處理程序然後恢復該進程的狀態並返回到用戶程序。

現在，在系統調用期間有兩種關於上下文切換的內核。 先發制人和非先發制人的內核（粗略地說，因爲這有時也適用於執行代碼關鍵部分的線程/進程）。

前者在RTOS（實時操作系統）中很常見，而後者在我們所知道的最常見的操作系統中很常見。
在搶佔式內核中，調度程序可以選擇退出執行系統調用的線程，以獲得更高優先級的線程。 後者不允許這種搶先，如在;如果某個線程當前正在執行一個系統調用，則所有其他線程都應該等待，直到完成其內核模式工作。

總結起來，通常在非RT系統中，如果一個線程執行系統調用，它應該在調度之前完成其工作。

現在注意一些事情，一些系統調用可能會阻止！
這是什麼意思？這意味着他們會停下來直到中斷髮生，然後他們會回來執行，直到他們完成工作。
一個例子是read（），它將阻塞直到用戶請求的數據準備就緒;同時其他線程可以計劃運行，但是一旦有中斷髮生，read（）就會再次開始運行，並且沒有人可以調度它（再次，只在非搶佔環境中），直到它返回給用戶登陸結果。

Answer 3

首先，在Linux中使用一些術語。在Linux中，內核可以在幾個上下文中運行的：

• 過程上下文（用戶上下文）：內核代表用戶 -space 過程，這已被稱爲系統調用的運行，是讀取/proc文件，...
• 中斷上下文：內核正在響應某個中斷而運行。
• 原子上下文：由於某種原因，內核無法入睡（阻塞）：也許它在中斷上下文中運行，或者某個螺旋鎖被鎖定，...
• 非原子上下文：顯然，我希望。

系統調用與中斷開始執行啓用（或者是因爲他們都明確地重新啓用（例如：當使用的x86的sysenter），或因爲他們根本就不會被禁用（如：使用x86的陷阱門，當它的Linux」 int 0x80確實））。因此，內核在執行系統調用時可能被中斷中斷。

某些系統調用可能會睡眠（阻塞），等待某件事。在這種情況下，內核可以切換到另一個任務（進程/線程），稍後喚醒睡眠任務。

在非搶佔內核，任務無法搶佔了在過程上下文中運行（即實際做的工作，不睡覺），另一項任務。在搶佔式內核中，較高優先級的任務可以搶佔在非原子進程上下文中運行的較低優先級任務。這可以防止高級的上下文切換延遲，g：一個音頻程序可能需要非常頻繁地調度，搶先式內核可以防止其他任務的繁重系統調用處理與此混淆（否則可能導致音頻失真，點擊......）