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