socket阻塞與非阻塞，同步與異步

簡單點說:

阻塞就是幹不完不許回來，   
非組賽就是你先幹，我現看看有其餘事沒有，完了告訴我一聲

咱們拿最經常使用的send和recv兩個函數來講吧... 
好比你調用send函數發送必定的Byte,在系統內部send作的工做其實只是把數據傳輸(Copy)到TCP/IP協議棧的輸出緩衝區,它執行成功並不表明數據已經成功的發送出去了,若是TCP/IP協議棧沒有足夠的可用緩衝區來保存你Copy過來的數據的話...這時候就體現出阻塞和非阻塞的不一樣之處了:對於阻塞模式的socket send函數將不返回直到系統緩衝區有足夠的空間把你要發送的數據Copy過去之後才返回,而對於非阻塞的socket來講send會當即返回WSAEWOULDDBLOCK告訴調用者說:"發送操做被阻塞了!!!你想辦法處理吧..." 
對於recv函數,一樣道理,該函數的內部工做機制實際上是在等待TCP/IP協議棧的接收緩衝區通知它說:嗨,你的數據來了.對於阻塞模式的socket來講若是TCP/IP協議棧的接收緩衝區沒有通知一個結果給它它就一直不返回:耗費着系統資源....對於非阻塞模式的socket該函數會立刻返回,而後告訴你:WSAEWOULDDBLOCK---"如今沒有數據,回頭在來看看"

在進行網絡編程時，咱們經常見到同步、異步、阻塞和非阻塞四種調用方式。這些方式彼此概念並很差理解。下面是我對這些術語的理解。
同步
      所謂同步，就是在發出一個功能調用時，在沒有獲得結果以前，該調用就不返回。按照這個定義，其實絕大多數函數都是同步調用（例如sin, isdigit等）。可是通常而言，咱們在說同步、異步的時候，特指那些須要其餘部件協做或者須要必定時間完成的任務。最多見的例子就是 SendMessage。該函數發送一個消息給某個窗口，在對方處理完消息以前，這個函數不返回。當對方處理完畢之後，該函數才把消息處理函數所返回的 LRESULT值返回給調用者。
異步
      異步的概念和同步相對。當一個異步過程調用發出後，調用者不能馬上獲得結果。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。以 CAsycSocket類爲例（注意，CSocket從CAsyncSocket派生，可是起功能已經由異步轉化爲同步），當一個客戶端經過調用 Connect函數發出一個鏈接請求後，調用者線程馬上能夠朝下運行。當鏈接真正創建起來之後，socket底層會發送一個消息通知該對象。這裏提到執行 部件和調用者經過三種途徑返回結果：狀態、通知和回調。可使用哪種依賴於執行部件的實現，除非執行部件提供多種選擇，不然不受調用者控制。若是執行部 件用狀態來通知，那麼調用者就須要每隔必定時間檢查一次，效率就很低（有些初學多線程編程的人，總喜歡用一個循環去檢查某個變量的值，這實際上是一種很嚴重 的錯誤）。若是是使用通知的方式，效率則很高，由於執行部件幾乎不須要作額外的操做。至於回調函數，其實和通知沒太多區別。

阻塞
     阻塞調用是指調用結果返回以前，當前線程會被掛起。函數只有在獲得結果以後纔會返回。有人也許會把阻塞調用和同步調用等同起來，實際上他是不一樣的。對於同 步調用來講，不少時候當前線程仍是激活的，只是從邏輯上當前函數沒有返回而已。例如，咱們在CSocket中調用Receive函數，若是緩衝區中沒有數 據，這個函數就會一直等待，直到有數據才返回。而此時，當前線程還會繼續處理各類各樣的消息。若是主窗口和調用函數在同一個線程中，除非你在特殊的界面操 做函數中調用，其實主界面仍是應該能夠刷新。socket接收數據的另一個函數recv則是一個阻塞調用的例子。當socket工做在阻塞模式的時候， 若是沒有數據的狀況下調用該函數，則當前線程就會被掛起，直到有數據爲止。
非阻塞
      非阻塞和阻塞的概念相對應，指在不能馬上獲得結果以前，該函數不會阻塞當前線程，而會馬上返回。
對象的阻塞模式和阻塞函數調用
對象是否處於阻塞模式和函數是否是阻塞調用有很強的相關性，可是並非一一對應的。阻塞對象上能夠有非阻塞的調用方式，咱們能夠經過必定的API去輪詢狀 態，在適當的時候調用阻塞函數，就能夠避免阻塞。而對於非阻塞對象，調用特殊的函數也能夠進入阻塞調用。函數select就是這樣的一個例子。

 

阻塞通訊

--------------------------------------------------------------------------------

經過重疊通訊和計算在許多系統能提升性能。由一個智能通訊控制器自動地執行通訊的系統是真實的。輕－重線索是取得這種重疊的一種機制。致使好性能的 一個可選的機制是使用非阻塞通訊。一個阻塞發送開始調用初始化這個發送操做，但不完成它。在這個消息被從這個發送緩存拷出之前，這個發送開始調用將返回。 須要一個獨立的「發送完成」調用完成這個通訊，例如，檢驗從發送緩存拷出的數據。用適當的硬件，在發送被初始化後和它完成之前，來自發送者存儲的數據轉換 能夠和在發送者完成的計算同時進行。相似地，一個非阻塞「接收開始調用」初始化這個接收操做, 但不完成它。在一個消息被存入這個接收緩存之前，這個調用將返回。需要一個獨立的「接收完成」調用完成這個接收操做，並檢驗被接收到這個接收緩存的數據。 用適當的硬件，在接收操做初始化後和它完成之前，到接收者存儲的數據轉換能夠和計算同時進行。非阻塞接收的使用雖着信息較早地在接收緩存位置被提供，也可 以免系統緩存和存儲器到存儲器拷貝。

非阻塞發送開始調用能使用與阻塞發送同樣的四種模式: 標準, 緩存, 同步和準備好模式。這些具備一樣的意義。不管一個匹配接收是否已登入，能開始除「準備好」之外的全部模式的發送；只要一個匹配接收已登入，就能開始一個非 阻塞「準備好」發送。在全部狀況下，發送開始調用是局部的：不管其它進程的狀態如何，它馬上返回。若是這個調用使得一些系統資源用完，那麼它將失敗並返回 一個錯誤代碼。高質量的MPI實現應保證這種狀況只在「病態」時發生。即，一個MPI實現將能支持大數量掛起非阻塞操做。　　

當數據已被從發送緩存拷出時，這個發送完成調用返回。它能夠帶有附加的意義，這取決於發送模式。　　

若是發送模式是「同步的」，那麼只有一個匹配接收已開始這個發送才能完成。即，一個接收已被登入，並已和這個發送匹配。這時，這個發送完成調用是非 局部的。注意，在接收完成調用發生之前，若是一個同步、非阻塞發送和一個非阻塞接收匹配, 它能夠完成。(發送者一「知道」轉換將結束，它就能完成，但在接收者「知道」轉換將結束之前)。　　

若是發送模式是「緩存」，並無掛起接收，那麼消息必須被緩存。這時，發送完成調用是局部的，並且不管一個匹配接收的狀態如何，它必須成功。　　

若是發送模式是標準的，同時這個消息被緩存，那麼在一個匹配接收發生之前，發送結束調用能夠返回。另外一方面，發送完成直到一個匹配接收發生才能夠完成，而且這個消息已被拷到接收緩存。　　

非阻塞發送能被用阻塞接收匹配，反過來也能夠。 　　

給用戶的建議. 一個發送操做的完成, 對於標準模式能夠被延遲, 對於同部模式必須延遲, 直到一個匹配接收登入。這兩種狀況下非阻塞發送的使用容許發送者提早於接收者進行，以便在兩進程的速度方面，計算更容忍波動。　　

緩存和準備好模式中的非阻塞發送有一個更有限的影響。一可能一個非阻塞發送將返回，而一個阻塞發送將在數據被從發送者存儲拷出後返回。只要在數據拷貝能和計算同時的狀況下，非阻塞發送的使用有優勢。　　

消息發送模式隱含着由發送者初始化通訊。當發送者初始化通訊(數據被直接移到接收緩存, 並不要求排隊一個掛起發送請求) 時，若是一個接收已登入，這個通訊通常將有較低的額外負擔。可是，只在匹配發送已發生後，一個接收操做能完成。當非阻塞接收等待發送時，沒有阻塞接收，它 的使用容許獲得較低的通訊額外負擔。