同步IO和異步IO,阻塞IO和非阻塞IO分别是什麼,到底有什麼區别?不同的人在不同的上下文下給出的答案是不同的。
一 概念說明在進行解釋之前,首先要說明幾個概念:
現在操作系統都是采用虛拟存儲器,那麼對32位操作系統而言,它的尋址空間(虛拟存儲空間)為4G(2的32次方)。操作系統的核心是内核,獨立于普通的應用程序,可以訪問受保護的内存空間,也有訪問底層硬件設備的所有權限。為了保證用戶進程不能直接操作内核(kernel),保證内核的安全,操心系統将虛拟空間劃分為兩部分,一部分為内核空間,一部分為用戶空間。
針對linux操作系統而言,将最高的1G字節(從虛拟地址0xC0000000到0xFFFFFFFF),供内核使用,稱為内核空間。
而将較低的3G字節(從虛拟地址0x00000000到0xBFFFFFFF),供各個進程使用,稱為用戶空間。
進程切換為了控制進程的執行,内核必須有能力挂起正在CPU上運行的進程,并恢複以前挂起的某個進程的執行。這種行為被稱為進程切換。因此可以說,任何進程都是在操作系統内核的支持下運行的,是與内核緊密相關的。
從一個進程的運行轉到另一個進程上運行,這個過程中經過下面這些變化:
1、保存處理機上下文,包括程序計數器和其他寄存器。2、更新PCB信息。3、把進程的PCB移入相應的隊列,如就緒、在某事件阻塞等隊列。4、選擇另一個進程執行,并更新其PCB。5、更新内存管理的數據結構。6、恢複處理機上下文。7、總而言之就是很耗資源
進程的阻塞正在執行的進程,由于期待的某些事件未發生,如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等,則由系統自動執行阻塞原語(Block),使自己由運行狀态變為阻塞狀态。可見,進程的阻塞是進程自身的一種主動行為,也因此隻有處于運行态的進程(獲得CPU),才可能将其轉為阻塞狀态。當進程進入阻塞狀态,是不占用CPU資源的。
文件描述符fd文件描述符(File descriptor)是計算機科學中的一個術語,是一個用于表述指向文件的引用的抽象化概念。
文件描述符在形式上是一個非負整數。實際上,它是一個索引值,指向内核為每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時,内核向進程返回一個文件描述符。在程序設計中,一些涉及底層的程序編寫往往會圍繞着文件描述符展開。但是文件描述符這一概念往往隻适用于UNIX、Linux這樣的操作系統。
緩存 I/O緩存 I/O 又被稱作标準 I/O,大多數文件系統的默認 I/O 操作都是緩存 I/O。在 Linux 的緩存 I/O 機制中,操作系統會将 I/O 的數據緩存在文件系統的頁緩存( page cache )中,也就是說,數據會先被拷貝到操作系統内核的緩沖區中,然後才會從操作系統内核的緩沖區拷貝到應用程序的地址空間。
緩存 I/O 的缺點:數據在傳輸過程中需要在應用程序地址空間和内核進行多次數據拷貝操作,這些數據拷貝操作所帶來的影響CPU以及内存開銷是非常大的。
二 IO模式剛才說了,對于一次IO訪問(以read舉例),數據會先被拷貝到操作系統内核的緩沖區中,然後才會從操作系統内核的緩沖區拷貝到應用程序的地址空間。所以說,當一個read操作發生時,它會經曆兩個階段:
1、等待數據準備 (Waiting for the data to be ready)2、将數據從内核拷貝到進程中 (copying the data from the kernel to the process)
正是因為這兩個階段,linux系統産生了下面五種網絡模式的方案。
注:由于signal driven IO在實際中并不常用,所以我這隻提及剩下的四種IO Model。
阻塞 I/O(blocking IO)在linux中,默認情況下所有的socket都是blocking,一個典型的讀操作流程大概是這樣:
當用戶進程調用了recvfrom這個系統調用,kernel就開始了IO的第一個階段:準備數據(對于網絡IO來說,很多時候數據在一開始還沒有到達。比如,還沒有收到一個完整的UDP包。這個時候kernel就要等待足夠的數據到來)。這個過程需要等待,也就是說數據被拷貝到操作系統内核的緩沖區中是需要一個過程的。而在用戶進程這邊,整個進程會被阻塞(當然,是進程自己選擇的阻塞)。當kernel一直等到數據準備好了,它就會将數據從kernel中拷貝到用戶内存,然後kernel返回結果,用戶進程才解除block的狀态,重新運行起來。
所以,blocking IO的特點就是在IO執行的兩個階段都被block了。
非阻塞 I/O(nonblocking IO)linux下,可以通過設置socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時,流程是這個樣子:
當用戶進程發出read操作時,如果kernel中的數據還沒有準備好,那麼它并不會block用戶進程,而是立刻返回一個error。從用戶進程角度io講 ,它發起一個read操作後,并不需要等待,而是馬上就得到了一個結果。用戶進程判斷結果是一個error時,它就知道數據還沒有準備好,于是它可以再次發送read操作。一旦kernel中的數據準備好了,并且又再次收到了用戶進程的system call,那麼它馬上就将數據拷貝到了用戶内存,然後返回。
所以,nonblocking IO的特點是用戶進程需要不斷的主動詢問kernel數據好了沒有。
I/O 多路複用( IO multiplexing)IO multiplexing就是我們說的select,poll,epoll,有些地方也稱這種IO方式為event driven IO。select/epoll的好處就在于單個process就可以同時處理多個網絡連接的IO。它的基本原理就是select,poll,epoll這個function會不斷地輪詢所負責的所有socket,當某個socket有數據到達了,就通知用戶進程。
當用戶進程調用了select,那麼整個進程會被block,而同時,kernel會“監視”所有select負責的socket,當任何一個socket中的數據準備好了,select就會返回。這個時候用戶進程再調用read操作,将數據從kernel拷貝到用戶進程。
所以,I/O 多路複用的特點是通過一種機制一個進程能同時等待多個文件描述符,而這些文件描述符(套接字描述符)其中的任意一個進入讀就緒狀态,select()函數就可以返回。
這個圖和blocking IO的圖其實并沒有太大的不同,事實上,還更差一些。因為這裡需要使用兩個system call (select 和 recvfrom),而blocking IO隻調用了一個system call (recvfrom)。但是,用select的優勢在于它可以同時處理多個connection。
所以,如果處理的連接數不是很高的話,使用select/epoll的web server不一定比使用multi-threading blocking IO的web server性能更好,可能延遲還更大。select/epoll的優勢并不是對于單個連接能處理得更快,而是在于能處理更多的連接。)
在IO multiplexing Model中,實際中,對于每一個socket,一般都設置成為non-blocking,但是,如上圖所示,整個用戶的process其實是一直被block的。隻不過process是被select這個函數block,而不是被socket IO給block。
異步 I/O(asynchronous IO)Linux下的asynchronous IO其實用得很少。先看一下它的流程:
I用戶進程發起read操作之後,立刻就可以開始去做其它的事。而另一方面,從kernel的角度,當它受到一個asynchronous read之後,首先它會立刻返回,所以不會對用戶進程産生任何block。然後,kernel會等待數據準備完成,然後将數據拷貝到用戶内存,當這一切都完成之後,kernel會給用戶進程發送一個signal,告訴它read操作完成了。
更多Linux内核視頻資料免費領取後台私信【内核】自行獲取。
内核學習網站:
Linux内核源碼/内存調優/文件系統/進程管理/設備驅動/網絡協議棧-學習視頻教程-騰訊課堂
人才交流:「鍊接」
總結blocking和non-blocking的區别調用blocking IO會一直block住對應的進程直到操作完成,而non-blocking IO在kernel還準備數據的情況下會立刻返回。
synchronous IO和asynchronous IO的區别在說明synchronous IO和asynchronous IO的區别之前,需要先給出兩者的定義。POSIX的定義是這樣子的:
- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
- An asynchronous I/O operation does not cause the requesting process to be blocked
兩者的區别就在于synchronous IO做”IO operation”的時候會将process阻塞。按照這個定義,之前所述的blocking IO,non-blocking IO,IO multiplexing都屬于synchronous IO。
有人會說,non-blocking IO并沒有被block啊。這裡有個非常“狡猾”的地方,定義中所指的”IO operation”是指真實的IO操作,就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候,如果kernel的數據沒有準備好,這時候不會block進程。但是,當kernel中數據準備好的時候,recvfrom會将數據從kernel拷貝到用戶内存中,這個時候進程是被block了,在這段時間内,進程是被block的。
而asynchronous IO則不一樣,當進程發起IO 操作之後,就直接返回再也不理睬了,直到kernel發送一個信号,告訴進程說IO完成。在這整個過程中,進程完全沒有被block。
各個IO Model的比較如圖所示:
通過上面的圖片,可以發現non-blocking IO和asynchronous IO的區别還是很明顯的。在non-blocking IO中,雖然進程大部分時間都不會被block,但是它仍然要求進程去主動的check,并且當數據準備完成以後,也需要進程主動的再次調用recvfrom來将數據拷貝到用戶内存。而asynchronous IO則完全不同。它就像是用戶進程将整個IO操作交給了他人(kernel)完成,然後他人做完後發信号通知。在此期間,用戶進程不需要去檢查IO操作的狀态,也不需要主動的去拷貝數據。
三 I/O 多路複用之select、poll、epoll詳解select,poll,epoll都是IO多路複用的機制。I/O多路複用就是通過一種機制,一個進程可以監視多個描述符,一旦某個描述符就緒(一般是讀就緒或者寫就緒),能夠通知程序進行相應的讀寫操作。但select,poll,epoll本質上都是同步I/O,因為他們都需要在讀寫事件就緒後自己負責進行讀寫,也就是說這個讀寫過程是阻塞的,而異步I/O則無需自己負責進行讀寫,異步I/O的實現會負責把數據從内核拷貝到用戶空間。
select
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
select 函數監視的文件描述符分3類,分别是writefds、readfds、和exceptfds。調用後select函數會阻塞,直到有描述副就緒(有數據 可讀、可寫、或者有except),或者超時(timeout指定等待時間,如果立即返回設為null即可),函數返回。當select函數返回後,可以 通過遍曆fdset,來找到就緒的描述符。
select目前幾乎在所有的平台上支持,其良好跨平台支持也是它的一個優點。select的一 個缺點在于單個進程能夠監視的文件描述符的數量存在最大限制,在Linux上一般為1024,可以通過修改宏定義甚至重新編譯内核的方式提升這一限制,但 是這樣也會造成效率的降低。
poll
int poll (struct pollfd *fds, unsigned int nfds, int timeout);
不同與select使用三個位圖來表示三個fdset的方式,poll使用一個 pollfd的指針實現。
struct pollfd { int fd; /* file descriptor */ short events; /* requested events to watch */ short revents; /* returned events witnessed */ };
pollfd結構包含了要監視的event和發生的event,不再使用select“參數-值”傳遞的方式。同時,pollfd并沒有最大數量限制(但是數量過大後性能也是會下降)。 和select函數一樣,poll返回後,需要輪詢pollfd來獲取就緒的描述符。
從上面看,select和poll都需要在返回後,通過遍曆文件描述符來獲取已經就緒的socket。事實上,同時連接的大量客戶端在一時刻可能隻有很少的處于就緒狀态,因此随着監視的描述符數量的增長,其效率也會線性下降。
epollepoll是在2.6内核中提出的,是之前的select和poll的增強版本。相對于select和poll來說,epoll更加靈活,沒有描述符限制。epoll使用一個文件描述符管理多個描述符,将用戶關系的文件描述符的事件存放到内核的一個事件表中,這樣在用戶空間和内核空間的copy隻需一次。
epoll操作過程epoll操作過程需要三個接口,分别如下:
1. int epoll_create(int size);
int epoll_create(int size);//創建一個epoll的句柄,size用來告訴内核這個監聽的數目一共有多大 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
創建一個epoll的句柄,size用來告訴内核這個監聽的數目一共有多大,這個參數不同于select()中的第一個參數,給出最大監聽的fd 1的值,參數size并不是限制了epoll所能監聽的描述符最大個數,隻是對内核初始分配内部數據結構的一個建議。 當創建好epoll句柄後,它就會占用一個fd值,在linux下如果查看/proc/進程id/fd/,是能夠看到這個fd的,所以在使用完epoll後,必須調用close()關閉,否則可能導緻fd被耗盡。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);函數是對指定描述符fd執行op操作。
- epfd:是epoll_create()的返回值。
- op:表示op操作,用三個宏來表示:添加EPOLL_CTL_ADD,删除EPOLL_CTL_DEL,修改EPOLL_CTL_MOD。分别添加、删除和修改對fd的監聽事件。
- fd:是需要監聽的fd(文件描述符)
- epoll_event:是告訴内核需要監聽什麼事,struct epoll_event結構如下:
struct epoll_event { __uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ };
events可以是以下幾個宏的集合:EPOLLIN :表示對應的文件描述符可以讀(包括對端SOCKET正常關閉);EPOLLOUT:表示對應的文件描述符可以寫;EPOLLPRI:表示對應的文件描述符有緊急的數據可讀(這裡應該表示有帶外數據到來);EPOLLERR:表示對應的文件描述符發生錯誤;EPOLLHUP:表示對應的文件描述符被挂斷;EPOLLET: 将EPOLL設為邊緣觸發(Edge Triggered)模式,這是相對于水平觸發(Level Triggered)來說的。EPOLLONESHOT:隻監聽一次事件,當監聽完這次事件之後,如果還需要繼續監聽這個socket的話,需要再次把這個socket加入到EPOLL隊列裡
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);等待epfd上的io事件,最多返回maxevents個事件。參數events用來從内核得到事件的集合,maxevents告之内核這個events有多大,這個maxevents的值不能大于創建epoll_create()時的size,參數timeout是超時時間(毫秒,0會立即返回,-1将不确定,也有說法說是永久阻塞)。該函數返回需要處理的事件數目,如返回0表示已超時。
工作模式epoll對文件描述符的操作有兩種模式:LT(level trigger)和ET(edge trigger)。LT模式是默認模式,LT模式與ET模式的區别如下:
1. LT模式
- LT模式:當epoll_wait檢測到描述符事件發生并将此事件通知應用程序,應用程序可以不立即處理該事件。下次調用epoll_wait時,會再次響應應用程序并通知此事件。
- ET模式:當epoll_wait檢測到描述符事件發生并将此事件通知應用程序,應用程序必須立即處理該事件。如果不處理,下次調用epoll_wait時,不會再次響應應用程序并通知此事件。
LT(level triggered)是缺省的工作方式,并且同時支持block和no-block socket.在這種做法中,内核告訴你一個文件描述符是否就緒了,然後你可以對這個就緒的fd進行IO操作。如果你不作任何操作,内核還是會繼續通知你的。
2. ET模式ET(edge-triggered)是高速工作方式,隻支持no-block socket。在這種模式下,當描述符從未就緒變為就緒時,内核通過epoll告訴你。然後它會假設你知道文件描述符已經就緒,并且不會再為那個文件描述符發送更多的就緒通知,直到你做了某些操作導緻那個文件描述符不再為就緒狀态了(比如,你在發送,接收或者接收請求,或者發送接收的數據少于一定量時導緻了一個EWOULDBLOCK 錯誤)。但是請注意,如果一直不對這個fd作IO操作(從而導緻它再次變成未就緒),内核不會發送更多的通知(only once)
ET模式在很大程度上減少了epoll事件被重複觸發的次數,因此效率要比LT模式高。epoll工作在ET模式的時候,必須使用非阻塞套接口,以避免由于一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。
3. 總結假如有這樣一個例子:
我們已經把一個用來從管道中讀取數據的文件句柄(RFD)添加到epoll描述符這個時候從管道的另一端被寫入了2KB的數據調用epoll_wait(2),并且它會返回RFD,說明它已經準備好讀取操作然後我們讀取了1KB的數據調用epoll_wait(2)……
LT模式: 如果是LT模式,那麼在第5步調用epoll_wait(2)之後,仍然能受到通知。
ET模式: 如果我們在第1步将RFD添加到epoll描述符的時候使用了EPOLLET标志,那麼在第5步調用epoll_wait(2)之後将有可能會挂起,因為剩餘的數據還存在于文件的輸入緩沖區内,而且數據發出端還在等待一個針對已經發出數據的反饋信息。隻有在監視的文件句柄上發生了某個事件的時候 ET 工作模式才會彙報事件。因此在第5步的時候,調用者可能會放棄等待仍在存在于文件輸入緩沖區内的剩餘數據。
當使用epoll的ET模型來工作時,當産生了一個EPOLLIN事件後,讀數據的時候需要考慮的是當recv()返回的大小如果等于請求的大小,那麼很有可能是緩沖區還有數據未讀完,也意味着該次事件還沒有處理完,所以還需要再次讀取:
while(rs){ buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0); if(buflen < 0){ // 由于是非阻塞的模式,所以當errno為EAGAIN時,表示當前緩沖區已無數據可讀 // 在這裡就當作是該次事件已處理處. if(errno == EAGAIN){ break; } else{ return; } } else if(buflen == 0){ // 這裡表示對端的socket已正常關閉. } if(buflen == sizeof(buf){ rs = 1; // 需要再次讀取 } else{ rs = 0; } }
Linux中的EAGAIN含義
Linux環境下開發經常會碰到很多錯誤(設置errno),其中EAGAIN是其中比較常見的一個錯誤(比如用在非阻塞操作中)。從字面上來看,是提示再試一次。這個錯誤經常出現在當應用程序進行一些非阻塞(non-blocking)操作(對文件或socket)的時候。
例如,以 O_NONBLOCK的标志打開文件/socket/FIFO,如果你連續做read操作而沒有數據可讀。此時程序不會阻塞起來等待數據準備就緒返回,read函數會返回一個錯誤EAGAIN,提示你的應用程序現在沒有數據可讀請稍後再試。又例如,當一個系統調用(比如fork)因為沒有足夠的資源(比如虛拟内存)而執行失敗,返回EAGAIN提示其再調用一次(也許下次就能成功)。
代碼演示下面是一段不完整的代碼且格式不對,意在表述上面的過程,去掉了一些模闆代碼。
epoll總結
#define IPADDRESS "127.0.0.1" #define PORT 8787 #define MAXSIZE 1024 #define LISTENQ 5 #define FDSIZE 1000 #define EPOLLEVENTS 100 listenfd = socket_bind(IPADDRESS,PORT); struct epoll_event events[EPOLLEVENTS]; //創建一個描述符 epollfd = epoll_create(FDSIZE); //添加監聽描述符事件 add_event(epollfd,listenfd,EPOLLIN); //循環等待 for ( ; ; ){ //該函數返回已經準備好的描述符事件數目 ret = epoll_wait(epollfd,events,EPOLLEVENTS,-1); //處理接收到的連接 handle_events(epollfd,events,ret,listenfd,buf); } //事件處理函數 static void handle_events(int epollfd,struct epoll_event *events,int num,int listenfd,char *buf) { int i; int fd; //進行遍曆;這裡隻要遍曆已經準備好的io事件。num并不是當初epoll_create時的FDSIZE。 for (i = 0;i < num;i ) { fd = events[i].data.fd; //根據描述符的類型和事件類型進行處理 if ((fd == listenfd) &&(events[i].events & EPOLLIN)) handle_accpet(epollfd,listenfd); else if (events[i].events & EPOLLIN) do_read(epollfd,fd,buf); else if (events[i].events & EPOLLOUT) do_write(epollfd,fd,buf); } } //添加事件 static void add_event(int epollfd,int fd,int state){ struct epoll_event ev; ev.events = state; ev.data.fd = fd; epoll_ctl(epollfd,EPOLL_CTL_ADD,fd,&ev); } //處理接收到的連接 static void handle_accpet(int epollfd,int listenfd){ int clifd; struct sockaddr_in cliaddr; socklen_t cliaddrlen; clifd = accept(listenfd,(struct sockaddr*)&cliaddr,&cliaddrlen); if (clifd == -1) perror("accpet error:"); else { printf("accept a new client: %s:%d\n",inet_ntoa(cliaddr.sin_addr),cliaddr.sin_port); //添加一個客戶描述符和事件 add_event(epollfd,clifd,EPOLLIN); } } //讀處理 static void do_read(int epollfd,int fd,char *buf){ int nread; nread = read(fd,buf,MAXSIZE); if (nread == -1) { perror("read error:"); close(fd); //記住close fd delete_event(epollfd,fd,EPOLLIN); //删除監聽 } else if (nread == 0) { fprintf(stderr,"client close.\n"); close(fd); //記住close fd delete_event(epollfd,fd,EPOLLIN); //删除監聽 } else { printf("read message is : %s",buf); //修改描述符對應的事件,由讀改為寫 modify_event(epollfd,fd,EPOLLOUT); } } //寫處理 static void do_write(int epollfd,int fd,char *buf) { int nwrite; nwrite = write(fd,buf,strlen(buf)); if (nwrite == -1){ perror("write error:"); close(fd); //記住close fd delete_event(epollfd,fd,EPOLLOUT); //删除監聽 }else{ modify_event(epollfd,fd,EPOLLIN); } memset(buf,0,MAXSIZE); } //删除事件 static void delete_event(int epollfd,int fd,int state) { struct epoll_event ev; ev.events = state; ev.data.fd = fd; epoll_ctl(epollfd,EPOLL_CTL_DEL,fd,&ev); } //修改事件 static void modify_event(int epollfd,int fd,int state){ struct epoll_event ev; ev.events = state; ev.data.fd = fd; epoll_ctl(epollfd,EPOLL_CTL_MOD,fd,&ev); } //注:另外一端我就省了
在 select/poll中,進程隻有在調用一定的方法後,内核才對所有監視的文件描述符進行掃描,而epoll事先通過epoll_ctl()來注冊一 個文件描述符,一旦基于某個文件描述符就緒時,内核會采用類似callback的回調機制,迅速激活這個文件描述符,當進程調用epoll_wait() 時便得到通知。(此處去掉了遍曆文件描述符,而是通過監聽回調的的機制。這正是epoll的魅力所在。)
epoll的優點主要是以下幾個方面:
1、監視的描述符數量不受限制,它所支持的FD上限是最大可以打開文件的數目,這個數字一般遠大于2048,舉個例子,在1GB内存的機器上大約是10萬左右,具體數目可以cat /proc/sys/fs/file-max查看,一般來說這個數目和系統内存關系很大。select的最大缺點就是進程打開的fd是有數量限制的。這對 于連接數量比較大的服務器來說根本不能滿足。雖然也可以選擇多進程的解決方案( Apache就是這樣實現的),不過雖然linux上面創建進程的代價比較小,但仍舊是不可忽視的,加上進程間數據同步遠比不上線程間同步的高效,所以也不是一種完美的方案。
2、IO的效率不會随着監視fd的數量的增長而下降。epoll不同于select和poll輪詢的方式,而是通過每個fd定義的回調函數來實現的。隻有就緒的fd才會執行回調函數。
如果沒有大量的idle-connection或者dead-connection,epoll的效率并不會比select/poll高很多,但是當遇到大量的idle-connection,就會發現epoll的效率大大高于select/poll。
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!