Scheduling
正在執行阻塞系統呼叫的執行緒是否被中斷喚醒？
我一直在讀一些關於執行緒和中斷的文章。有一節說使用執行緒進行並行程式更簡單，因為我們不必擔心中斷。
但是，如果不是中斷，則表示釋放阻塞系統呼叫的機制是什麼？
例子
我在我的執行緒中讀取 i 文件，該文件使用阻塞系統呼叫從磁碟讀取文件。
在此期間，其他執行緒正在執行。
在某個時刻，該文件已準備好從硬碟讀取。
它是否通過硬體中斷通知處理器，以便它可以對請求文件的執行緒進行上下文切換？
中斷由作業系統處理，執行緒（或程序，就此而言）甚至不知道它們。
在您繪製的場景中：
- 您的執行緒發出
read()系統呼叫；核心收到請求，意識到執行緒在數據到達（阻塞呼叫）之前不會做任何事情，因此執行緒被阻塞。- 核心為緩衝區分配空間（如果需要），並啟動“找到要讀取的塊，請求將該塊讀入緩衝區”的舞蹈。
- 調度器選擇另一個執行緒來使用剛剛釋放的 CPU
- 一切順其自然，直到……
- …一個中斷從磁碟到達。核心接管，看到這標誌著之前發出的讀取完成，並標記執行緒準備好。控制權返回使用者空間。
- 一切順其自然，直到……
- … 有人通過一千個原因中的一個讓出 CPU，而剛剛釋放的 CPU 恰好被分配給正在等待數據的執行緒。
反正就是這樣。不，當中斷發生以指示傳輸完成時，CPU 不會分配給等待執行緒。它可能會中斷另一個執行緒，並且執行可能會恢復該執行緒（或者可能會選擇另一個執行緒）。