|
|
寫這個系列原本的想法是討論一下.NET中異步編程風格的變化，特別是F#中的異步工作流以及未來的.NET 5.0中的基于任務的異步編程模型。但經過前幾篇文章（為什么需要異步，傳統的異步編程，使用CPS及yield實現異步）的發表后，很多人對IO異步背后實現的原理以及為什么這樣能提高性能很感興趣。其實我本不想花更多的文字在這些底層實現的細節上，一來我并不擅長這些方面，二來我們使用.NET的異步IO就不需要關心這些底層東西，因為已經為你封裝完備了。不過為了避免大家一再在這上面商討，我還是在這個系列中間插入了一篇來解釋一下。
本文我將從內核對象IO完成端口開始介紹，然后來瞧瞧.NET BCL中的FileStream.BeginRead是如何利用IO完成端口來實現的。
IO完成端口(IO Completion Port)
大多數人應該或多或少地聽說過IO完成端口這么個東西，而且也知道它是實現高性能IO，高伸縮性應用的尚方寶劍。IO完成端口是一個非常復雜的內核對象，其實現的也非常巧妙，細細琢磨還是非常有意思的。
創建高伸縮性的應用的一個基本原則就是：創建更少的線程。線程數更少首先消耗的資源就少，每個線程的創建除了要浪費CPU時間外，還要創建一系列的數據結構用來保存線程相關的一些信息：用戶棧，線程上下文，內核棧等。這個總共加起來大概1.5M左右，那么你算算你的32位機器總共能使用多少內存?那么對應地能創建多少線程?可能有人講那對于64位的就無所謂了。嗯，在資源占用這方面64位確實不用擔心。但是系統中可運行的線程數越多，你的CPU數又是有限的(8個?80個?)。Windows的任務調度機制是每個線程會運行一個時間片，然后Windows搶占式的調度另一個線程運行。那么線程數越多，Windows勢必要進行更頻繁的線程上下文切換。線程上下文切換對系統性能的影響在這里我就不多說了，你可以搜搜資料。
那么如何做到創建更少的線程，而又干更多的事兒呢?答案就是“不等待”。相對CPU來說，IO設備的速度簡直低的要命。就好像飛機和拖拉機的差別一樣，我們可不能讓拖拉機拖了飛機的后退兒。而IO完成端口就是為了這個而生的：創建更少的線程，干更多的事兒。
IO完成端口首先不是一個我們看得見摸得著的什么插口，也和我們常說的80這樣的端口不同。你可以將其理解為一個數據結構或一個對象(下面我會用C#的代碼來輔助講解IO完成端口，僅僅是講解，這些代碼并不是真實的實現)：
Windows提供了一個CreateIoCompletionPort API來創建IO完成端口，實際上這個API有兩個作用：創建IO完成端口和將一個IO設備與該端口綁定。創建IO完成端口時有一個很重要的參數：指定同時最多能有多少個線程并行運行，這就是為了保證更少的線程，如果你將這個數值指定為0，那么默認值就會是你機器的CPU數。IO端口里還有一個IO設備句柄列表，你可以將很多設備句柄與這個端口綁定(文件、Socket等)：
//函數原型
HANDLE CreateIoCompletionPort(
//設備句柄
HANDLE hFile,
//已有的IO完成端口句柄，如果這里已經指定，則是將前面指定的設備與該端口綁定
HANDLE hExistingCompletionPort,
//因為一個IO完成端口可以綁定很多設備，可以用這個來區分
ULONG_PTR CompletionKey,
//允許同時運行的線程數
DWORD dwNumberOfConcurrentThreads
);
//創建一個IO完成端口
HANDLE hIoPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL,0,2);
//創建文件，如果要異步訪問文件則需要指定FILE_FLAG_OVERLAPPED
HANDLE hFile = CreateFile(..);
//將上面創建的文件句柄與剛才創建的IO完成端口綁定，不僅僅是文件可以
CreateIoCompletionPort(hFile,hIoPort,1,2);
NET技術：.NET異步編程：IO完成端口與BeginRead，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
