您好,登錄后才能下訂單哦!
這篇文章主要介紹“什么是進(jìn)程間通信”,在日常操作中,相信很多人在什么是進(jìn)程間通信問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”什么是進(jìn)程間通信”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
多進(jìn)程協(xié)作主要有以下三點優(yōu)勢。
將功能模塊化,避免重復(fù)造輪子。
增強(qiáng)模塊間的隔離,提供更強(qiáng)的安全保障。
提高應(yīng)用的容錯能力。
進(jìn)程間通信(Inter-Process Communication,IPC)則是多進(jìn)程協(xié)作的基礎(chǔ)。一般而言,IPC至少需要兩方(如兩個進(jìn)程)參與。根據(jù)信息流動的方向,這兩方通常被稱為發(fā)送者和接收者。在實際使用中,IPC經(jīng)常被用于服務(wù)調(diào)用,因此參與IPC的兩方又被稱為調(diào)用者和被調(diào)用者,或者客戶端和服務(wù)端。
圖7-1是一個簡單的IPC設(shè)計。它假設(shè)內(nèi)核已為兩個進(jìn)程映射了一段共享內(nèi)存,且共享內(nèi)存剛好可以存放兩個消息(發(fā)送者消息和接受者消息)。
1. 數(shù)據(jù)傳遞
消息傳遞(message passing)是IPC中常用的數(shù)據(jù)傳遞方式,即將數(shù)據(jù)抽象成一個個的消息進(jìn)行傳遞。不同的IPC設(shè)計有不同的消息抽象,且消息傳遞往往需要一個“中間人”(如共享內(nèi)存)。
2. 控制流轉(zhuǎn)移
當(dāng)一個通信發(fā)生時,內(nèi)核將控制流從發(fā)送者進(jìn)程切換到接收者進(jìn)程(返回的過程類似)。IPC中的控制流轉(zhuǎn)移,通常是利用內(nèi)核對進(jìn)程的運行狀態(tài)和運行時間的控制來實現(xiàn)的。
1. 單向IPC、雙向IPC、單/雙向IPC
單向IPC通常指消息在一個連接上只能從一端發(fā)送到另一端,雙向IPC則允許雙方互相發(fā)送消息。而單/雙向IPC則會根據(jù)通信中具體的配置選項等來判斷是否需要支持單向或雙向的通信。實際中,很多系統(tǒng)選擇的是單/雙向IPC,這樣可以比較好地支持各種場景。當(dāng)然,如管道、信號等只支持單向IPC的機(jī)制在實際中同樣有較多的應(yīng)用。
2. 同步IPC和異步IPC
簡單來看,同步IPC指它的IPC操作(如Send)會阻塞進(jìn)程直到該操作完成;而異步IPC則通常是非阻塞的,進(jìn)程只要發(fā)起一次操作即可返回,而不需要等待其完成。
相比異步而言,同步IPC有著更好的編程抽象。然而同步IPC在操作系統(tǒng)的發(fā)展中,逐漸表現(xiàn)出一些不足。一個典型的問題是并發(fā)??偟膩砜矗壳按蟛糠植僮飨到y(tǒng)內(nèi)核都會選擇同時實現(xiàn)同步和異步IPC,以滿足不同的應(yīng)用需求。
1. 超時機(jī)制
超時機(jī)制擴(kuò)展了IPC通信雙方的接口,允許發(fā)送者/接收者指定它們發(fā)送/接收請求的等待時間。比如,一個應(yīng)用程序可以花費5秒等待文件系統(tǒng)進(jìn)程的IPC請求處理操作。如果超過5秒仍然沒有反饋,則由操作系統(tǒng)內(nèi)核結(jié)束這次IPC調(diào)用,返回一個超時的錯誤。
2. 通信連接管理
對于基于共享內(nèi)存的進(jìn)程間通信方案,通信連接的建立通常是在建立共享區(qū)域的一瞬間完成的;而對于涉及內(nèi)核的控制流轉(zhuǎn)移的通信而言,通信連接管理是內(nèi)核IPC模塊的很重要的一部分。
雖然實際的系統(tǒng)中會有各種不同的實現(xiàn),但是它們大部分可以被歸為兩類——直接通信和間接通信。直接通信是指通信的進(jìn)程一方需要顯式地標(biāo)識另一方。間接通信需要經(jīng)過一個中間的信箱來完成通信,每個信箱有自己唯一的標(biāo)識符,而進(jìn)程間通過共享一個信箱來交換消息。
3. 權(quán)限檢查
進(jìn)程間通信通常依賴于一套權(quán)限檢查的機(jī)制來保證連接的安全性。例如,seL4等微內(nèi)核系統(tǒng)中的Capability機(jī)制,會將所有的通信連接抽象成一個個的內(nèi)核對象。而每個進(jìn)程對內(nèi)核對象的訪問權(quán)限(以及能夠在該內(nèi)核對象上執(zhí)行的操作)由Capability來刻畫。
當(dāng)一個進(jìn)程企圖和某其他進(jìn)程通信時,內(nèi)核會檢查該進(jìn)程是否擁有一個Capability,是否有足夠的權(quán)限訪問一個連接對象并且對象是指向目標(biāo)進(jìn)程的。類似地,宏內(nèi)核,如Linux系統(tǒng),通常會復(fù)用其有效用戶/有效組的文件權(quán)限,以刻畫進(jìn)程對于某個連接的權(quán)限。
4. 命名服務(wù)
命名服務(wù)像是一個全局的看板,可以協(xié)調(diào)服務(wù)端進(jìn)程和客戶端進(jìn)程之間的信息。簡單來說,服務(wù)端進(jìn)程可以將自己提供的服務(wù)告訴命名服務(wù)進(jìn)程,比如文件系統(tǒng)進(jìn)程可以注冊一個“文件系統(tǒng)服務(wù)”,網(wǎng)絡(luò)系統(tǒng)進(jìn)程可以注冊一個“網(wǎng)絡(luò)服務(wù)”。
而客戶端進(jìn)程可以去命名服務(wù)上查詢當(dāng)前的服務(wù),并選擇自己希望建立連接的服務(wù)去嘗試獲取權(quán)限。具體是否分發(fā)權(quán)限給對應(yīng)的客戶端進(jìn)程,是由命名服務(wù)和對應(yīng)的服務(wù)端進(jìn)程根據(jù)特定的策略來判斷的。
宏內(nèi)核下的典型的進(jìn)程間通信機(jī)制,具體包括管道,System V中的消息隊列、信號量、共享內(nèi)存,Linux信號機(jī)制,以及套接字機(jī)制(socket)。
宏內(nèi)核操作系統(tǒng)中進(jìn)程間通信更多的是應(yīng)用之間的交互,因此,設(shè)計的重心通常會放在接口的易用性、穩(wěn)定性等方面。圖7-5給出了典型的宏內(nèi)核進(jìn)程間通信機(jī)制的對比。
可以看到,雖然在IPC的幾個設(shè)計角度上幾個方案都各有異同,但是它們之間的主要區(qū)別是在數(shù)據(jù)抽象上。在實際的應(yīng)用中,雖然多種IPC方案都可以作為通信的選擇,但是應(yīng)用程序往往會根據(jù)對數(shù)據(jù)抽象的需求來選擇具體的方案。
由于進(jìn)程間通信對于微內(nèi)核系統(tǒng)性能的重要意義,大部分微內(nèi)核操作系統(tǒng)都會優(yōu)先從性能角度來設(shè)計和實現(xiàn)進(jìn)程間通信。
1. Mach:早期的微內(nèi)核進(jìn)程間通信設(shè)計
Mach通過兩種基本的抽象——端口(port)和消息(message),設(shè)計和實現(xiàn)了一種間接通信IPC:通信的雙方不需要顯式指定另一方,而是通過端口進(jìn)行通信(對應(yīng)于“信箱”)。進(jìn)程之間通過端口流通的數(shù)據(jù)就是消息。
作為一個早期的微內(nèi)核系統(tǒng),Mach系統(tǒng)的性能比起當(dāng)時的宏內(nèi)核系統(tǒng)(如UNIX)還是存在不小的差距。其中一個原因是Mach為了實現(xiàn)大量的目標(biāo),如可裁剪性、可移植性等,導(dǎo)致其內(nèi)核復(fù)雜,且代碼量較大。不過,Mach的IPC設(shè)計仍對后來的很多系統(tǒng)有著非常重大的影響。
Mach中端口和消息的設(shè)計使得進(jìn)程間的通信和具體的進(jìn)程是隔離開的。只要一個進(jìn)程擁有某個端口,其就能夠通過這個端口和“另一端”的進(jìn)程進(jìn)行通信。后續(xù)的微內(nèi)核系統(tǒng)設(shè)計大都考慮了Mach的思想,不管是借鑒其設(shè)計還是將其缺陷引以為戒。
2. L4:圍繞進(jìn)程間通信優(yōu)化而設(shè)計的微內(nèi)核系統(tǒng)
根據(jù)Mach的經(jīng)驗,Liedtke等研究人員開始研發(fā)L4系列的微內(nèi)核系統(tǒng)。L4系列微內(nèi)核系統(tǒng)的一個突出思路是:進(jìn)程間通信是微內(nèi)核的核心功能,需要圍繞通信去完成整個系統(tǒng)的設(shè)計和實現(xiàn)。L4是當(dāng)下仍然十分主流的微內(nèi)核系統(tǒng),特別是后續(xù)衍生出了各種變體和相關(guān)的系統(tǒng)。
在L4微內(nèi)核中,內(nèi)核只保留了基本的功能,包括地址空間、線程、進(jìn)程間通信等,并且不考慮如兼容性等要求,而是選擇針對特定硬件做極致的性能優(yōu)化。這樣做的好處就是內(nèi)核的代碼量非常少,可以把少量的功能盡可能支持好。
3. LRPC:遷移線程模型
遷移線程(thread migration)是一個比較“極端”的優(yōu)化性能的IPC設(shè)計。截止到目前,我們了解到優(yōu)化IPC性能的大部分工作會關(guān)注兩個部分:優(yōu)化控制流切換的性能和優(yōu)化數(shù)據(jù)傳輸?shù)男阅堋?/p>
遷移線程認(rèn)為,其他的IPC設(shè)計可以看成將需要處理的數(shù)據(jù)發(fā)送到另一個進(jìn)程并讓其處理。這也是為什么控制流切換和數(shù)據(jù)傳輸會成為主要的瓶頸。
如果換一個角度,將另一個進(jìn)程處理數(shù)據(jù)的代碼拉到當(dāng)前進(jìn)程,那么我們是不是可以避免控制流的切換(仍然是當(dāng)前進(jìn)程處理)以及數(shù)據(jù)傳輸(數(shù)據(jù)已經(jīng)準(zhǔn)備在當(dāng)前進(jìn)程中)呢?遷移線程就是圍繞這個新的視角進(jìn)行設(shè)計的。
遷移線程方案被用在LRPC、Mach(優(yōu)化版本)等系統(tǒng)中,是目前純軟件進(jìn)程間通信優(yōu)化中效果最好的設(shè)計之一。遷移線程的基本原則是:
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)
簡化控制流切換,讓客戶端線程執(zhí)行“服務(wù)端的代碼”;
簡化數(shù)據(jù)傳輸,共享參數(shù)棧和寄存器;
簡化接口,減少序列化等開銷;
優(yōu)化并發(fā),避免共享的全局?jǐn)?shù)據(jù)結(jié)構(gòu)。其中,前兩點原則都基于“將代碼拉到本地”這個新的視角。
遷移線程IPC和主流IPC設(shè)計的對比如圖7-13所示。要做到“將代碼拉到本地”,遷移線程首先需要對線程結(jié)構(gòu)進(jìn)行解耦,明確線程中哪些部分是對通信請求處理起關(guān)鍵作用的。然后,這部分允許被調(diào)用者(負(fù)責(zé)處理請求的邏輯)運行在調(diào)用者的上下文中,將跨進(jìn)程調(diào)用變成更接近函數(shù)調(diào)用的形式。
如果使用遷移線程模型,在進(jìn)程間通信過程中,內(nèi)核不會阻塞調(diào)用者線程,但是會讓調(diào)用者線程執(zhí)行被調(diào)用者的代碼。整個過程沒有被調(diào)用者線程被喚醒,相反,被調(diào)用者端更像是一個“代碼提供者”。
此外,內(nèi)核不會進(jìn)行完整的上下文切換,而是只切換地址空間(頁表)等和請求處理相關(guān)的系統(tǒng)狀態(tài)。其中,不會涉及線程和優(yōu)先級的切換,也不會調(diào)用調(diào)度器。遷移線程的優(yōu)點在于減少了內(nèi)核調(diào)度的時間,并簡化了內(nèi)核中的IPC處理。在多核場景下,遷移線程方案還可以避免跨核通信引入的開銷。
在Android場景下,進(jìn)程間通信在大部分情況下做的其實是“遠(yuǎn)程過程調(diào)用”。服務(wù)端進(jìn)程負(fù)責(zé)提供具體的服務(wù),客戶端進(jìn)程則通過進(jìn)程間通信來發(fā)起服務(wù)請求,并獲得服務(wù)端進(jìn)程處理后的結(jié)果。
除了通信雙方進(jìn)程外,在Binder IPC中還引入了一個Context Manager進(jìn)程。Context Manager提供命名服務(wù),它的任務(wù)是建立通信連接。
在Binder IPC的內(nèi)核設(shè)計中,提供了句柄(handle)的抽象來表示IPC對象(即一個通信連接)。句柄和我們熟悉的文件描述符其實很相似,用戶通過對句柄的操作來發(fā)起對特定進(jìn)程的通信。
和之前的進(jìn)程間通信設(shè)計不同的一點是,Binder IPC中采用了“線程池”的服務(wù)端模型。也就是說,在服務(wù)端中,Binder的用戶態(tài)和內(nèi)核會有一個響應(yīng)線程池的概念。當(dāng)某個客戶端進(jìn)程發(fā)起通信時,內(nèi)核會從(服務(wù)端的)線程池中選擇一個可用的線程來響應(yīng)。這種設(shè)計能夠在同步進(jìn)程間通信的情況下比較好地處理并發(fā)的通信請求。
到此,關(guān)于“什么是進(jìn)程間通信”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注億速云網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。