這里沒有執行緒
原文地址：https://blog.stephencleary.com/2013/11/there-is-no-thread.html
前言
我是在看 C#8.0 新特性異步流時在評論里看到這篇文章的，閱讀之后發現這篇文章干貨滿滿，作者解釋的非常清晰，里面的本質分析內容在《CLR via C#》一書中也有講到，更加加深了我的印象，遂在這里翻譯過來，以便加深自己的理解
正文
一個本質的事實就是純粹的異步是不會產生執行緒的
反對這個事實的人有很多，“不”，他們喊道：“如果我正在等待一個操作，那么這個執行緒就必須在執行等待！它可能是執行緒池執行緒，或者是一個作業系統（OS）執行緒，又或是其他設備驅動程式...”
無需理會他們，如果一個異步操作是純粹的（pure），那么就不會有執行緒的，
那些持懷疑態度的人，那我們就迎合他們罷，
我們將跟蹤一個異步操作一直到硬體，特別是 .net 部分和硬體部分，我們必須通過省略一些中間的細節來簡化描述，但是我們不能偏離事實真相，
通常寫一個異步操作（檔案，網路流，USB 介面等等），代碼如下：
private async void Button_Click(object sender, RoutedEventArgs s)
{
byte[] data = https://www.cnblogs.com/treeskyer/p/...
await myDevice.WriteAsync(data, 0, data.Length);
}
我們已經知道在 await 的時候 UI 執行緒是不會阻塞的，那么問題來了：這里有沒有是其他執行緒在阻塞期間犧牲自己以至于讓 UI 執行緒存活呢？
那讓我們繼續往下深究
第一步：庫（比如進入到 BCL 庫源代碼），我們假使 WriteAsync 是通過 [http://msdn.microsoft.com/en-us/library/system.threading.overlapped.aspx](P/Invoke 在 .net 異步的標準實作) 來實作的，它是基于overllapped I/O 的，所有它在一個設備驅動程式的句柄上開始一個 Win32 overlapped 操作，
OVERLAPPED 是一個包含了用于異步輸入輸出的資訊的結構體；詳細解釋移步 https://en.wikipedia.org/wiki/Overlapped_I/O
作業系統然后就會轉向設備驅動程式并開始請求一個寫操作，它首先會構造一個表示寫請求的物件；它被稱為 I/O Request Packet(IRP)，
設備驅動程式接受到 IRP 之后并向設備提交一個寫出資料的命令，如果這個設備支持直接記憶體訪問（DMA 全稱是 Direct Memory Access），這能夠像寫到緩沖區到暫存器一樣簡單，這就是設備驅動程式所做的一切；它把 IRP 標記為 "pending" (掛起) 并回傳給作業系統，
本質核心就在這里：設備驅動程式正在處理 IRP 時是不會允許阻塞的，也就是說如果 IRP 不能馬上完成，那么它必須要異步處理，甚至是同步 API 也是如此！在設備驅動程式級別，所有的請求（重要的）都是異步的，
這里參考了 Tomes 的知識，“無論I/O請求的型別如何，在內部，代表應用程式向驅動程式發出的I/O操作都是異步執行的”
在 IRP 掛起的時候，OS 回傳庫，庫回傳了一個未完成的任務給按鈕點擊事件，并暫停了 async 方法， UI 執行緒繼續執行，
我們跟著請求繼續往下走，現在到達了設備的物理層
現在寫操作正在進行，那么有多少執行緒正處理它呢？
沒有，
這里沒有設備驅動程式執行緒、OS 執行緒、庫（BCL）執行緒或者是執行緒池執行緒操作寫操作，這里沒有執行緒，
現在我們來跟著從來自內核的相應回到最初的世界，
在開始寫請求之后的一段時間，設備完成了寫操作，它會以中斷的方式來通知 CPU，
設備驅動程式的中斷服務程式（ISR(Interrupt Service Routine) ）回應中斷，這個中斷是 CPU 級別的事件，無論哪個執行緒正在運行都會臨時的搶占 CPU 的控制權，你可以認為 ISR 是在“借”當前正在運行的執行緒，但是我更傾向于 ISR 運行時的級別非常低，以至于不存在“執行緒”的概念，可以這么說，它們在所有執行緒之下進來的，
不管怎樣，ISR 正確寫完了，完了它會通知設備程式 “謝謝你的中斷” 并且進入 DPC（Deffered Procedure Call） 佇列（延遲程序呼叫）
當 CPU 被中斷干擾時，它將會到達 DPCs，DPCs 也會執行在一個很低的級別以至于說它是一個執行緒是不正確的；就像 ISRs，DPCs 直接在 CPU 上運行，在執行緒系統之下，
PDC 接受代表寫請求的 IRP 并且標記為 “已完成”，然而，這個“完成”狀態只存在于 OS 級別；行程有它自己的記憶體空間，它必須被通知，所以 OS 會入佇列一個特殊內核模式異步程序呼叫（APC）到擁有自己句柄的執行緒，
由于 BCL 庫使用了標準的 P/Invoke overlapped I/O 系統，它已經在 I/O Completion Port（IOCP）注冊句柄，它是執行緒池的一部分，所以借用 I/O 執行緒池執行緒來執行 APC，它會通知這些任務已經完成了，
這個任務已經捕捉了 UI 背景關系，所以它不會直接在執行緒池執行緒上恢復異步方法，而是它將該方法的延續排隊到 UI 背景關系中，并且 UI 執行緒將恢復執行那個方法，
所以我們看到，正當一個請求處理時這里是沒有執行緒的，當請求完成時，一些執行緒被借過去或者是被短暫的排隊，這項作業通常在 1 毫秒左右（例如 APC 運行在執行緒池執行緒）或 1 微妙左右（例如 ISR），但是這里沒有執行緒是阻塞的，僅僅只是等待請求完成，
現在，我們遵循的路徑是標準路徑，這是如此清晰簡單，這里有無數的變數，但是核心是不變的，
所以說 “這里必須有一個執行緒是在處理異步操作” 是不正確的，
釋懷吧，不要嘗試找到異步執行緒——這是不可能的，而是你應該去了解真相：
沒有執行緒
該篇文章的評論也是很精彩的，特別是討論將異步操作當作訊息處理那部分討論，建議也花時間看下
本文同步至：https://github.com/MarsonShine/MarsonShine.github.io/blob/master/mardown/async/There-IS-NO-Thread.md
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/57152.html
標籤：其他