淺談Python基礎之I/O模型，淺談pythono模型

淺談Python基礎之I/O模型，淺談pythono模型

一、I/O模型

IO在電腦中指Input/Output，也就是輸入和輸出。由於程式和運行時資料是在記憶體中駐留，由CPU這個超快的計算核心來執行，涉及到資料交換的地方，通常是磁碟、網路等，就需要IO介面。

同步（synchronous） IO和非同步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分別是什麼，到底有什麼區別？

這個問題其實不同的人給出的答案都可能不同，比如wiki，就認為asynchronous IO和non-blocking IO是一個東西。這其實是因為不同的人的知識背景不同，並且在討論這個問題的時候上下文(context)也不相同。所以，為了更好的回答這個問題，先限定一下本文的上下文。
本文討論的背景是Linux環境下的network IO。

Stevens在文章中一共比較了五種IO Model：

blocking IO（阻塞IO）

nonblocking IO （非阻塞IO）

IO multiplexing （IO多工）

asynchronous IO （非同步IO）

signal driven IO （訊號驅動IO）

由於signal driven IO在實際中並不常用，所以我這隻提及剩下的四種IO Model。

再說一下IO發生時涉及的對象和步驟。

對於一個network IO (這裡我們以read舉例)，它會涉及到兩個系統對象，一個是調用這個IO的process (or thread)，另一個就是系統核心(kernel)。當一個read操作發生時，它會經曆兩個階段：

等待資料準備 (Waiting for the data to be ready)
將資料從核心拷貝到進程中 (Copying the data from the kernel to the process)
記住這兩點很重要，因為這些IO Model的區別就是在兩個階段上各有不同的情況。

二、 blocking IO

在linux中，預設情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：

當使用者進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備資料。對於network IO來說，很多時候資料在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的資料到來。而在使用者進程這邊，整個進程會被阻塞。當kernel一直等到資料準備好了，它就會將資料從kernel中拷貝到使用者記憶體，然後kernel返回結果，使用者進程才解除block的狀態，重新運行起來。

所以，blocking IO的特點就是在IO執行的兩個階段都被block了。

三、non-blocking IO

linux下，可以通過設定socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：

可以看出，當使用者進程發出read操作時，如果kernel中的資料還沒有準備好，那麼它並不會block使用者進程，而是立刻返回一個error。從使用者進程角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。使用者進程判斷結果是一個error時，它就知道資料還沒有準備好，於是它可以再次發送read操作。一旦kernel中的資料準備好了，並且又再次收到了使用者進程的system call，那麼它馬上就將資料拷貝到了使用者記憶體，然後返回。所以，使用者進程其實是需要不斷的主動詢問kernel資料好了沒有。

注意：

在網路IO時候，非阻塞IO也會進行recvform系統調用，檢查資料是否準備好，與阻塞IO不一樣，”非阻塞將大的整片時間的阻塞分成N多的小的阻塞, 所以進程不斷地有機會 ‘被' CPU光顧”。即每次recvform系統調用之間，cpu的許可權還在進程手中，這段時間是可以做其他事情的，也就是說非阻塞的recvform系統調用之後，進程並沒有被阻塞，核心馬上返回給進程，如果資料還沒準備好，此時會返回一個error。進程在返回之後，可以幹點別的事情，然後再發起recvform系統調用。重複上面的過程，迴圈往複的進行recvform系統調用。這個過程通常被稱之為輪詢。輪詢檢查核心資料，直到資料準備好，再拷貝資料到進程，進行資料處理。需要注意，拷貝資料整個過程，進程仍然是屬於阻塞的狀態。

import timeimport socketsk = socket.socket(socket.AF_INET, socket.SOCK_STREAM)sk.bind(('127.0.0.1', 8080))sk.listen(5)sk.setblocking(False)  #設定通訊端為非阻塞模式while True:  try:    print('waiting client connection .......')    connection, address = sk.accept() # 進程主動輪詢    print("+++", address)    client_messge = connection.recv(1024)    print(str(client_messge, 'utf8'))    connection.close()  except Exception as e:    print(e)    time.sleep(4)#############################clientimport timeimport socketsk = socket.socket(socket.AF_INET,socket.SOCK_STREAM)while True:  sk.connect(('127.0.0.1', 8080))  print("hello")  sk.sendall(bytes("hello", "utf8"))  time.sleep(2)  break

以上執行個體，服務段端每隔4秒輪詢一次，若沒有任何用戶端連結，則會拋出錯誤資訊，並繼續輪詢。

非阻塞IO：

優點：能夠在等待任務完成的時間裡幹其他活了（包括提交其他任務，也就是 “後台” 可以有多個任務在同時執行）。

缺點：任務完成的響應延遲增大了，因為每過一段時間才去輪詢一次read操作，而任務可能在兩次輪詢之間的任意時間完成，導致不能即時擷取資料，這也會導致整體資料輸送量的降低。

四、IO multiplexing

IO multiplexing這個詞可能有點陌生，有些地方也稱這種IO方式為event driven IO。我們都知道，select/epoll的好處就在於單個process就可以同時處理多個網路連接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有資料到達了，就通知使用者進程。它的流程

當使用者進程調用了select，那麼整個進程會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的資料準備好了，select就會返回。這個時候使用者進程再調用read操作，將資料從kernel拷貝到使用者進程。

這個圖和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。

注意：

1.select函數返回結果中如果有檔案可讀了，那麼進程就可以通過調用accept()或recv()來讓kernel將位於核心中準備到的資料copy到使用者區。

2.select的優勢在於可以處理多個串連，不適用於單個串連

import select, socketsock = socket.socket()sock.bind(('127.0.0.1', 8080))sock.listen(5)sock.setblocking(False)listen_obj = [sock, ]while True:  r, w, e = select.select(listen_obj, [], [])  for obj in r:    if obj == sock:      conn, addr = obj.accept()      print('conn', conn)      print('addr', addr)      listen_obj.append(conn)    else:      data = obj.recv(1024)      print(data.decode('utf8'))      send_data = input('>>>')      obj.send(send_data.encode('utf8'))#############################clientimport socketsock = socket.socket()sock.connect(('127.0.0.1', 8080))while True:  data = input('>>>')  sock.send(data.encode('utf8'))  recv_data = sock.recv(1024)  print(recv_data.decode('utf8'))sock.close()

以上執行個體，服務端kernel監聽select負責的listen_obj中的所有socket對象。當任何一個socket對象啟用，根據其類型判斷是否建立通訊。

五、asynchronous I/O

linux下的asynchronous IO其實用得很少。先看一下它的流程：

使用者進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它收到一個asynchronous read之後，首先它會立刻返回，所以不會對使用者進程產生任何block。然後，kernel會等待資料準備完成，然後將資料拷貝到使用者記憶體，當這一切都完成之後，kernel會給使用者進程發送一個signal，告訴它read操作完成了。

很明顯，使用非同步IO來編寫程式效能會遠遠高於同步IO，但是非同步IO的缺點是編程模型複雜。

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操作的狀態，也不需要主動的去拷貝資料。

以上這篇淺談Python基礎之I/O模型就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支援幫客之家。