終于有人把進程間通信講明白了
多進程協作主要有以下三點優勢。
- 將功能模塊化，避免重復造輪子。
- 增強模塊間的隔離，提供更強的安全保障。
- 提高應用的容錯能力。
進程間通信(Inter-Process Communication，IPC)則是多進程協作的基礎。一般而言，IPC至少需要兩方(如兩個進程)參與。根據信息流動的方向，這兩方通常被稱為發送者和接收者。在實際使用中，IPC經常被用于服務調用，因此參與IPC的兩方又被稱為調用者和被調用者，或者客戶端和服務端。
圖7-1是一個簡單的IPC設計。它假設內核已為兩個進程映射了一段共享內存，且共享內存剛好可以存放兩個消息(發送者消息和接受者消息)。
01 進程間通信的重要功能
1. 數據傳遞
消息傳遞(message passing)是IPC中常用的數據傳遞方式，即將數據抽象成一個個的消息進行傳遞。不同的IPC設計有不同的消息抽象，且消息傳遞往往需要一個“中間人”(如共享內存)。
2. 控制流轉移
當一個通信發生時，內核將控制流從發送者進程切換到接收者進程(返回的過程類似)。IPC中的控制流轉移，通常是利用內核對進程的運行狀態和運行時間的控制來實現的。
02 進程間通信的分類
1. 單向IPC、雙向IPC、單/雙向IPC
單向IPC通常指消息在一個連接上只能從一端發送到另一端，雙向IPC則允許雙方互相發送消息。而單/雙向IPC則會根據通信中具體的配置選項等來判斷是否需要支持單向或雙向的通信。實際中，很多系統選擇的是單/雙向IPC，這樣可以比較好地支持各種場景。當然，如管道、信號等只支持單向IPC的機制在實際中同樣有較多的應用。
2. 同步IPC和異步IPC
簡單來看，同步IPC指它的IPC操作(如Send)會阻塞進程直到該操作完成;而異步IPC則通常是非阻塞的，進程只要發起一次操作即可返回，而不需要等待其完成。
相比異步而言，同步IPC有著更好的編程抽象。然而同步IPC在操作系統的發展中，逐漸表現出一些不足。一個典型的問題是并發。總的來看，目前大部分操作系統內核都會選擇同時實現同步和異步IPC，以滿足不同的應用需求。
03 進程間通信的相關機制
1. 超時機制
超時機制擴展了IPC通信雙方的接口，允許發送者/接收者指定它們發送/接收請求的等待時間。比如，一個應用程序可以花費5秒等待文件系統進程的IPC請求處理操作。如果超過5秒仍然沒有反饋，則由操作系統內核結束這次IPC調用，返回一個超時的錯誤。
2. 通信連接管理
對于基于共享內存的進程間通信方案，通信連接的建立通常是在建立共享區域的一瞬間完成的;而對于涉及內核的控制流轉移的通信而言，通信連接管理是內核IPC模塊的很重要的一部分。
雖然實際的系統中會有各種不同的實現，但是它們大部分可以被歸為兩類——直接通信和間接通信。直接通信是指通信的進程一方需要顯式地標識另一方。間接通信需要經過一個中間的信箱來完成通信，每個信箱有自己唯一的標識符，而進程間通過共享一個信箱來交換消息。
3. 權限檢查
進程間通信通常依賴于一套權限檢查的機制來保證連接的安全性。例如，seL4等微內核系統中的Capability機制，會將所有的通信連接抽象成一個個的內核對象。而每個進程對內核對象的訪問權限(以及能夠在該內核對象上執行的操作)由Capability來刻畫。
當一個進程企圖和某其他進程通信時，內核會檢查該進程是否擁有一個Capability，是否有足夠的權限訪問一個連接對象并且對象是指向目標進程的。類似地，宏內核，如Linux系統，通常會復用其有效用戶/有效組的文件權限，以刻畫進程對于某個連接的權限。
4. 命名服務
命名服務像是一個全局的看板，可以協調服務端進程和客戶端進程之間的信息。簡單來說，服務端進程可以將自己提供的服務告訴命名服務進程，比如文件系統進程可以注冊一個“文件系統服務”，網絡系統進程可以注冊一個“網絡服務”。
而客戶端進程可以去命名服務上查詢當前的服務，并選擇自己希望建立連接的服務去嘗試獲取權限。具體是否分發權限給對應的客戶端進程，是由命名服務和對應的服務端進程根據特定的策略來判斷的。
04 宏內核進程間通信
宏內核下的典型的進程間通信機制，具體包括管道，System V中的消息隊列、信號量、共享內存，Linux信號機制，以及套接字機制(socket)。
宏內核操作系統中進程間通信更多的是應用之間的交互，因此，設計的重心通常會放在接口的易用性、穩定性等方面。圖7-5給出了典型的宏內核進程間通信機制的對比。
可以看到，雖然在IPC的幾個設計角度上幾個方案都各有異同，但是它們之間的主要區別是在數據抽象上。在實際的應用中，雖然多種IPC方案都可以作為通信的選擇，但是應用程序往往會根據對數據抽象的需求來選擇具體的方案。
05 微內核進程間通信
由于進程間通信對于微內核系統性能的重要意義，大部分微內核操作系統都會優先從性能角度來設計和實現進程間通信。
1. Mach：早期的微內核進程間通信設計
Mach通過兩種基本的抽象——端口(port)和消息(message)，設計和實現了一種間接通信IPC：通信的雙方不需要顯式指定另一方，而是通過端口進行通信(對應于“信箱”)。進程之間通過端口流通的數據就是消息。
作為一個早期的微內核系統，Mach系統的性能比起當時的宏內核系統(如UNIX)還是存在不小的差距。其中一個原因是Mach為了實現大量的目標，如可裁剪性、可移植性等，導致其內核復雜，且代碼量較大。不過，Mach的IPC設計仍對后來的很多系統有著非常重大的影響。
Mach中端口和消息的設計使得進程間的通信和具體的進程是隔離開的。只要一個進程擁有某個端口，其就能夠通過這個端口和“另一端”的進程進行通信。后續的微內核系統設計大都考慮了Mach的思想，不管是借鑒其設計還是將其缺陷引以為戒。
2. L4：圍繞進程間通信優化而設計的微內核系統
根據Mach的經驗，Liedtke等研究人員開始研發L4系列的微內核系統。L4系列微內核系統的一個突出思路是：進程間通信是微內核的核心功能，需要圍繞通信去完成整個系統的設計和實現。L4是當下仍然十分主流的微內核系統，特別是后續衍生出了各種變體和相關的系統。
在L4微內核中，內核只保留了基本的功能，包括地址空間、線程、進程間通信等，并且不考慮如兼容性等要求，而是選擇針對特定硬件做極致的性能優化。這樣做的好處就是內核的代碼量非常少，可以把少量的功能盡可能支持好。
3. LRPC：遷移線程模型
遷移線程(thread migration)是一個比較“極端”的優化性能的IPC設計。截止到目前，我們了解到優化IPC性能的大部分工作會關注兩個部分：優化控制流切換的性能和優化數據傳輸的性能。
遷移線程認為，其他的IPC設計可以看成將需要處理的數據發送到另一個進程并讓其處理。這也是為什么控制流切換和數據傳輸會成為主要的瓶頸。
如果換一個角度，將另一個進程處理數據的代碼拉到當前進程，那么我們是不是可以避免控制流的切換(仍然是當前進程處理)以及數據傳輸(數據已經準備在當前進程中)呢?遷移線程就是圍繞這個新的視角進行設計的。
遷移線程方案被用在LRPC、Mach(優化版本)等系統中，是目前純軟件進程間通信優化中效果最好的設計之一。遷移線程的基本原則是：
- 簡化控制流切換，讓客戶端線程執行“服務端的代碼”;
- 簡化數據傳輸，共享參數棧和寄存器;
- 簡化接口，減少序列化等開銷;
- 優化并發，避免共享的全局數據結構。其中，前兩點原則都基于“將代碼拉到本地”這個新的視角。
遷移線程IPC和主流IPC設計的對比如圖7-13所示。要做到“將代碼拉到本地”，遷移線程首先需要對線程結構進行解耦，明確線程中哪些部分是對通信請求處理起關鍵作用的。然后，這部分允許被調用者(負責處理請求的邏輯)運行在調用者的上下文中，將跨進程調用變成更接近函數調用的形式。
如果使用遷移線程模型，在進程間通信過程中，內核不會阻塞調用者線程，但是會讓調用者線程執行被調用者的代碼。整個過程沒有被調用者線程被喚醒，相反，被調用者端更像是一個“代碼提供者”。
此外，內核不會進行完整的上下文切換，而是只切換地址空間(頁表)等和請求處理相關的系統狀態。其中，不會涉及線程和優先級的切換，也不會調用調度器。遷移線程的優點在于減少了內核調度的時間，并簡化了內核中的IPC處理。在多核場景下，遷移線程方案還可以避免跨核通信引入的開銷。
06 案例分析：Android Binder
在Android場景下，進程間通信在大部分情況下做的其實是“遠程過程調用”。服務端進程負責提供具體的服務，客戶端進程則通過進程間通信來發起服務請求，并獲得服務端進程處理后的結果。
除了通信雙方進程外，在Binder IPC中還引入了一個Context Manager進程。Context Manager提供命名服務，它的任務是建立通信連接。
在Binder IPC的內核設計中，提供了句柄(handle)的抽象來表示IPC對象(即一個通信連接)。句柄和我們熟悉的文件描述符其實很相似，用戶通過對句柄的操作來發起對特定進程的通信。
和之前的進程間通信設計不同的一點是，Binder IPC中采用了“線程池”的服務端模型。也就是說，在服務端中，Binder的用戶態和內核會有一個響應線程池的概念。當某個客戶端進程發起通信時，內核會從(服務端的)線程池中選擇一個可用的線程來響應。這種設計能夠在同步進程間通信的情況下比較好地處理并發的通信請求。
