linux下的IO模型詳解

2021-10-11 05:11:20 字數 1238 閱讀 2570

開門見山,linux下的如中io模型:阻塞io模型,非阻塞io模型,io復用模型,訊號驅動io模型,非同步io模型,見下圖

接下來一一講解這5種模型

阻塞型io:最簡單的一種io模型,簡單理解就是死等,即程序或執行緒一直等待莫格條件,不滿足則一直等待。

非阻塞型io:應用程序與核心互動,目的未達到之前會直接返回,然後不斷輪詢,不停的去問核心資料是否準備好?如果發現準備好了,那就把資料拷貝到使用者空間中。應用程序通過

recvfrom 呼叫不停的去和核心互動,直到核心準備好資料。如果沒有準備好,內

核會返回error,應用程序在得到error後,過一段時間再傳送recvfrom請求。在兩次傳送請求的時間段,程序可以先做別的事情。

訊號驅動io:我們會發現非阻塞型io方式一遍一遍的輪詢不如等核心把資料準備好,然後通知程序,當程序收到該通知時,便開始把資料拷貝到使用者空間中。

即應用程序預先向核心註冊乙個訊號處理函式,然後使用者程序返回,並不阻塞,當核心資料準備就緒時會傳送乙個訊號給程序,使用者程序便在訊號處理函式中開始把資料拷貝到使用者空間中

io復用模型:顧名思義,即將多個程序i/0註冊到同一管道上,這裡管道會統一和核心互動。當管道中的某乙個請求需要好的資料準備好之後,程序再把對應的資料拷貝到使用者空間中。i/o多路轉接是多了乙個select函式,多個程序的io可以註冊到同乙個select中,使用者呼叫該select。select會監聽所有註冊好的i/o,如果所有被監聽的i/o需要的資料都沒有準備好,select呼叫程序會阻塞。當任意乙個i/o所需要的資料準備好之後,select呼叫就

會返回,然後程序再通過recvfrom來進行資料拷貝。但實際上,它並未向核心註冊訊號處理函式,所以它並不是非阻塞的。

看到開篇的那張圖,大家肯定會有疑問,為什麼之前的這四種模型都是同步的呢?因為無論以上哪種模型,真正的資料拷貝過程都是同步的(自己的理解便是:所有的資料拷貝過程都是使用者程序手動執行的) 分享乙個linux io的參考資料:

那麼我們來看真正非同步執行的i/o模型:

非同步i/o模型:應用程序把i/o請求傳給核心後,完全由核心去操作檔案拷貝。核心完成相關操作後,會發訊號告訴應用程序本次i/o已經完成。使用者程序發起aio_read操作之後,給核心傳遞描述符、緩衝區指標、緩衝區大小等,告訴核心程序當整個操作完成時,如何通知程序,然後就立刻去做其他事兒了。當核心收到aio_read後,會立刻返回,然後核心開始等待資料準備,資料準備好以後,直接把資料拷貝到使用者控制項,然後再通知程序本次io已經完成。

更多交流學習可以私我暱稱wx號 各個模型的執行流程比較圖如下圖所示

linux下的IO模型詳解

開門見山,linux下的如中io模型 阻塞io模型,非阻塞io模型,io復用模型,訊號驅動io模型,非同步io模型,見下圖 接下來一一講解這5種模型 阻塞型io 最簡單的一種io模型,簡單理解就是死等,即程序或執行緒一直等待莫格條件,不滿足則一直等待。非阻塞型io 應用程序與核心互動,目的未達到之前...

linux下的io模型

因為作業系統的資源是有限的,如果訪問資源的操作過多,必然會消耗過多的資源,而且如果不對這些操作加以區分,很可能造成資源訪問的衝突。所以,為了減少有限資源的訪問和使用衝突,unix linux的設計哲學之一就是 對不同的操作賦予不同的執行等級,就是所謂特權的概念。簡單說就是有多大能力做多大的事,與系統...

Linux下常見的IO模型

前三種都是同步,只有最後一種才是非同步io。簡介 程序會一直阻塞,直到資料拷貝完成。應用程式呼叫乙個io函式,導致應用程式阻塞,等待資料準備好。如果資料沒有準備好,一直等待。資料準備好了,從核心拷貝到使用者空間。執行完畢後,io函式會向應用程式返回成功響應,應用程式得到響應後,就不再阻塞,並進行後面...