POLL, SELECT & EPOLL 原理比較分析

原文出處：http://www.cnblogs.com/sharra/archive/2010/12/30/1921287.html

因為需要瞭解底層裝置訪問的原理，所以慣用高層應用語言的我，需要瞭解一下Linux的裝置訪問機制，尤其是處理一組非阻塞IO的原理方法，標準的術語好像是叫多工。以下文章部分句子有引用之處，恕沒有一一指出出處。

 

對於接觸過Linux核心或裝置驅動開發的讀者，一定清楚poll和select系統調用，以及從2.5版本引入的epoll機制（epoll機制包含三個系統調用）。網上關於它們的文章，有說用法的，甚為詳細，更有分析原始碼的，又比較深入，且枝節頗多。經過幾篇文章的閱讀，我把覺得比較核心的東西寫下來吧。我的用意是儘可能以簡單的概念，比對他們三者的異同。

 

幾經尋找我才確定下來，poll和select應該被歸類為這樣的系統調用，它們可以阻塞地同時探測一組支援非阻塞的IO裝置，是否有事件發生（如可讀，可寫，有高優先順序的錯誤輸出，出現錯誤等等），直至某一個裝置觸發了事件或者超過了指定的等待時間——也就是它們的職責不是做IO，而是協助調用者尋找當前就緒的裝置。同類型的產品是Windows的IOCP，它也是處理多工，只是把IO和探測封裝在了一起了。

 

準備的知識有兩點：1、fd；2、op->poll。

在Linux裡面，裝置都被抽象為檔案，一系列的裝置檔案就有自己獨立的虛擬檔案系統，所以，裝置在系統調用參數中的表示就是file description。fd其實就是一個整數（特別地，標準輸入，輸出，錯誤輸出分別對應的fd是0，1，2）。與核心打交道的時候，傳遞整數的fd可以在自己的檔案系統中作進一步的檢查是否合法，如果只是返回指標就不能這樣操作了，畢竟指標是無差別無意義的。

通過fd訪問file，通過file可以訪問其fileOperator，這裡面我們要關心的一個fileOp就是poll。因為系統調用poll和select，就是依靠這個檔案操作poll實現的。poll檔案操作有兩個參數，一個是檔案本身，一個可以看做是當裝置尚未就緒時調用的回呼函數，這個函數是把裝置自己特有的等待隊列傳給核心，讓核心把當前的進程掛載到其中（因為當裝置就緒時，裝置就應該去喚醒在自己特有等待隊列中的所有節點，這樣當前進程就擷取了完成的訊號了）。poll檔案操作返回的必須是一組標準的掩碼，其中的各個位指示當前的不同的就緒狀態（全0為沒有任何事件觸發）。

 

再談談早期多工版本poll和select。

本質而言，poll和select的共同點就是，對全部指定裝置做一次poll，當然這往往都是還沒有就緒的，那就會通過回呼函數把當前進程註冊到裝置的等待隊列，如果所有裝置返回的掩碼都沒有顯示任何的事件觸發，就去掉回呼函數的函數指標，進入有限時的睡眠狀態，再恢複和不斷做poll，再作有限時的睡眠，直到其中一個裝置有事件觸發為止。只要有事件觸發，系統調用返回，回到使用者態，使用者就可以對相關的fd作進一步的讀或者寫操作了。當然，這個時候還不是所有的裝置都就緒的喔，那就得不斷地poll或者select了，而做一次這樣的系統調用都得輪詢所有的裝置，次數是裝置數*（睡眠次數-1），也就是時間複雜度是O（n），還得做幾次O（n）呢。可見，對於現在普遍的伺服器程式，需要同時並發監聽數千個串連，並且串連需要重複使用的情況，poll和select就存在這樣的效能瓶頸。另外，數千個裝置fd在每次調用時，都需要將其從使用者空間複製到核心空間，這裡的開銷不可忽略。

 

poll和select放在一起，是因為其機制一致，而參數和資料結構就略有不同。select一次性傳入三組作用於不同通道的裝置fd，分別是輸入，輸出和錯誤異常。各組的fd期待各組所特有的，由代碼指定的一組事件，如輸入通道期待輸入就緒，輸入掛起和錯誤等事件。 然後，select就挑選調用者關心的fd做poll檔案操作，檢測返回的掩碼，看看是否有fd所屬通道感興趣的事件，比如看看這個屬於輸出通道的fd有沒有輸出就緒等一系列的事件發生，一樣地，如果有一個fd發生感興趣事件就返回調用了。select，為了同時處理三組使用不同的事件判斷規則的fd，採用了位元影像的方式表示，一組一個位元影像，位長度是當中最大的fd值，上限是1024，三組就是3072，而且這還只是傳入的位元影像，還有一樣大小的傳出的位元影像。當fd數越來越多時，所需的儲存開銷比較大。

 

既然，一組fd處理起來比較粗放，那就各個fd自己準備好了。poll()系統調用是System
V的多元I/O解決方案。它有三個參數，第一個是pollfd結構的數組指標，也就是指向一組fd及其相關資訊的指標，因為這個結構包含的除了fd，還有期待的事件掩碼和返回的事件掩碼，實質上就是將select的中的fd，傳入和傳出參數歸到一個結構之下，也不再把fd分為三組，也不再硬性規定fd感興趣的事件，這由調用者自己設定。這樣，不使用位元影像來組織資料，也就不需要位元影像的全部遍曆了。按照一般隊列地遍曆，每個fd做poll檔案操作，檢查返回的掩碼是否有期待的事件，以及做是否有掛起和錯誤的必要性檢查，如果有事件觸發，就可以返回調用了。

 

回到poll和select的共同點，面對高並發多連線應用程式情境，它們顯現出原來沒有考慮到的不足，雖然poll比起select又有所改進了。除了上述的關於每次調用都需要做一次從使用者空間到核心空間的拷貝，還有這樣的問題，就是當處於這樣的應用情境時，poll和select會不得不多次操作，並且每次操作都很有可能需要多次進入睡眠狀態，也就是多次全部輪詢fd，我們應該怎麼處理一些會出現重複而無意義的操作。

 

這些重複而無意義的操作有：1、從使用者到核心空間拷貝，既然長期監視這幾個fd，甚至連期待的事件也不會改變，那拷貝無疑就是重複而無意義的，我們可以讓核心長期儲存所有需要監視的fd甚至期待事件，或者可以再需要時對部分期待事件進行修改；2、將當前線程輪流加入到每個fd對應裝置的等待隊列，這樣做無非是哪一個裝置就緒時能夠通知進程退出調用，聰明的開發人員想到，那就找個“代理”的回呼函數，代替當前進程加入fd的等待隊列好了（這也是我後來才總結出來，Linux的等待隊列，實質上是回呼函數隊列吧，也可以使用宏來將當前進程“加入”等待隊列，其實就是將喚醒當前進程的回呼函數排入佇列）。這樣，像poll系統調用一樣，做poll檔案操作發現尚未就緒時，它就調用傳入的一個回呼函數，這是epoll指定的回呼函數，它不再像以前的poll系統調用指定的回呼函數那樣，而是就將那個“代理”的回呼函數加入裝置的等待隊列就好了，這個代理的回呼函數就自己乖乖地等待裝置就緒時將它喚醒，然後它就把這個裝置fd放到一個指定的地方，同時喚醒可能在等待的進程，到這個指定的地方取fd就好了。我們把1和2結合起來就可以這樣做了，只拷貝一次fd，一旦確定了fd就可以做poll檔案操作，如果有事件當然好啦，馬上就把fd放到指定的地方，而通常都是沒有的，那就給這個fd的等待隊列加一個回呼函數，有事件就自動把fd放到指定的地方，當前進程不需要再一個個poll和睡眠等待了。

 

epoll機制就是這樣改進的了。誠然，fd少的時候，當前進程一個個地等問題不大，可是現在和尚多了，方丈就不好管了。以前裝置事件觸發時，只負責喚醒當前進程就好了，而當前進程也只能傻傻地在poll裡面等待或者迴圈，再來一次poll，也不知道這個由裝置提供的poll效能如何，能不能檢查出當前進程已經在等待了就立即返回，當然，我也不明白為什麼做了一遍的poll之後，去掉回呼函數指標了，還得再做，不是說好了會去喚醒進程的嗎？

 

現在就讓事件觸發回呼函數多做一步。本來裝置還沒就緒就調用一個回呼函數了，現在再在這個回呼函數裡面做一個註冊另一個回呼函數的操作，目的就是使得裝置事件觸發多走一步，不僅僅是喚醒當前進程，還要把自己的fd放到指定的地方。就像收本子的班長，以前得一個個學生地去問有沒有本子，如果沒有，它還得等待一段時間而後又繼續問，現在好了，只走一次，如果沒有本子，班長就告訴大家去那裡交本子，當班長想起要取本子，就去那裡看看或者等待一定時間後離開，有本子到了就叫醒他，然後取走。這個道理很簡單，就是老師和班幹們常說的，大家多做一點工作，我的工作就輕鬆很多了，尤其是需要管理的東西越來越多時。

 

這種機制或者說模式，我想在Java的FutureTask裡面應該也會用到的，一堆線上程池裡面跑著的線程（當然這是任務，不是線程，介面是Callable<V>，不是Runnable.run，是Callable.call，它是可以返回結果的），誰先做好就應該先處理呀，可是難道得一個個問嗎？乾脆就誰好了，誰就按照既定的操作暴露自己，這樣FutureTask的get方法就可以馬上知道當前最先完成的線程了，就可以取此線程返回結果了。

 

epoll由三個系統調用組成，分別是epoll_create，epoll_ctl和epoll_wait。epoll_create用於建立和初始化一些內部使用的資料結構；epoll_ctl用於添加，刪除或者修改指定的fd及其期待的事件，epoll_wait就是用於等待任何先前指定的fd事件。

 

關於epoll內部的資料結構，我就不能詳細瞭解了。