進程間為何要通訊 ?

鴻蒙內核默認支持 64個進程和128個任務,由進程池和任務池統一管理.內核設計盡量不去打擾它們,讓各自過好各自的日子, 但大家畢竟在一口鍋里吃飯, 不可能不與外界聯系, 聯系就得有渠道,有規矩.

舉兩個應用場景說明下通訊的必要性:

一.被動式廣為熟知的shell命令 kill 9 13 ,是通過 shell任務給 13號進程發送一個干掉它的信號.

#define SIGKILL   9		//常用的命令 kill 9 13 

這是被動式通訊的場景,至于為什么要干掉你,原因可能很多啊,很可能是檢測到13占用內存太多了,也可能13太低調長期不活躍,啟動新進程發現沒位置了,得先收了你.總之系統必須得有對付你的抓手,可以隨時登門查水電表.

二.主動式的,比如要訪問某些公共資源(全局變量,消息隊列),而資源有限或具有排他性,別人正在使用導致你不能用, 所以需統一管理,要用就必須要先申請,按規矩辦事,畢竟和諧社會沒規矩不成方圓.如果申請失敗了就需要排隊了,同時還要讓出CPU給別人占用了,否則占著茅坑不辦事這樣對大家都不好撒.

大致有以下幾種通訊需求:

(1).數據傳輸：一個進程需要將它的數據發送給另一個進程，發送的數據量在一個字節到KB字節之間.(liteipc消息隊列默認1K)

(2).共享數據:多個進程想要操作共享數據，一個進程對共享數據的修改，別的進程應該立刻看到。

(3).通知事件：一個進程需要向另一個或一組進程發送消息，通知它（它們）發生了某種事件（如進程終止時要通知父進程）。

(4).資源共享：多個進程之間共享同樣的資源。為了做到這一點，需要內核提供鎖和同步機制。

(5).進程控制：有些進程希望完全控制另一個進程的執行（如Debug進程），此時控制進程希望能夠攔截另一個進程的所有陷入和異常，并能夠及時知道它的狀態改變。

內核目錄和系列篇更新

內核有個專門的IPC目錄,詳見如下. 可直接點擊查看注解源碼.

進程間九種通訊方式

1.管道pipe(fs_syscall.c)

管道是一種最基本的IPC機制，作用于有血緣關系的進程之間，完成數據傳遞。 調用pipe系統函數即可創建一個管道。有如下特質：

其本質是一個偽文件(實為內核緩沖區)

由兩個文件描述符引用，一個表示讀端，一個表示寫端。

規定數據從管道的寫端流入管道，從讀端流出。

管道的原理: 管道實為內核使用環形隊列機制，借助內核緩沖區(4k)實現。 管道的局限性： ① 數據自己讀不能自己寫。 ② 數據一旦被讀走，便不在管道中存在，不可反復讀取。 ③ 由于管道采用半雙工通信方式。因此，數據只能在一個方向上流動。 ④ 只能在有公共祖先的進程間使用管道。 常見的通信方式有，單工通信、半雙工通信、全雙工通信。

這部分后系列篇文件相關篇中會重點講,敬請關注. 詳細看SysPipe函數.

2.信號(los_signal.c)

信號思想來自Unix,在發展了50年之后,許多方面都沒有發生太大的變化.信號可以由內核產生,也可以由用戶進程產生,并由內核傳送給特定的進程或線程(組),若這個進程注冊/安裝了自己的信號處理程序,則內核會調用這個函數去處理信號,否則則執行默認的函數或者忽略.信號分為兩大類：可靠信號與不可靠信號，前32種信號為不可靠信號，后32種為可靠信號。長這樣:

#define SIGHUP    1	//終端掛起或者控制進程終止
#define SIGINT    2	//鍵盤中斷（如break鍵被按下）
#define SIGQUIT   3	//鍵盤的退出鍵被按下
#define SIGILL    4	//非法指令
#define SIGTRAP   5	//跟蹤陷阱（trace trap），啟動進程，跟蹤代碼的執行
#define SIGABRT   6	//由abort(3)發出的退出指令
#define SIGIOT    SIGABRT 
#define SIGBUS    7	//總線錯誤 
#define SIGFPE    8	//浮點異常
#define SIGKILL   9		//常用的命令 kill 9 13 
#define SIGUSR1   10	//用戶自定義信號1 

信號為系統提供了一種進程間異步通訊的方式,一個進程不必通過任何操作來等待信號的到達。事實上，進程也不可能知道信號到底什么時候到達。一般來說，只需用戶進程提供信號處理函數，內核會想方設法調用信號處理函數,處理過程如圖所示:

個人把這種異步通訊過程理解為生產者(安裝和發送信號)和消費者(捕捉和處理信號)兩個部分,分姊妹兩篇已完成

v48.xx (信號生產篇) | 如何安裝和發送信號?

v49.xx (信號消費篇) | 用戶棧到內核棧的兩次切換

3.消息隊列(los_queue.c)

基本概念

隊列又稱消息隊列，是一種常用于任務間通信的數據結構。隊列接收來自任務或中斷的 不固定長度消息，并根據不同的接口確定傳遞的消息是否存放在隊列空間中。

任務能夠從隊列里面讀取消息，當隊列中的消息為空時，掛起讀取任務；當隊列中有新消息時， 掛起的讀取任務被喚醒并處理新消息。任務也能夠往隊列里寫入消息，當隊列已經寫滿消息時， 掛起寫入任務；當隊列中有空閑消息節點時，掛起的寫入任務被喚醒并寫入消息。如果將 讀隊列和寫隊列的超時時間設置為0，則不會掛起任務，接口會直接返回，這就是非阻塞模式。

消息隊列提供了異步處理機制，允許將一個消息放入隊列，但不立即處理。同時隊列還有緩沖消息的作用。

隊列特性

消息以先進先出的方式排隊，支持異步讀寫。 讀隊列和寫隊列都支持超時機制。 每讀取一條消息，就會將該消息節點設置為空閑。 發送消息類型由通信雙方約定，可以允許不同長度（不超過隊列的消息節點大小）的消息。 一個任務能夠從任意一個消息隊列接收和發送消息。 多個任務能夠從同一個消息隊列接收和發送消息。 創建隊列時所需的隊列空間，默認支持接口內系統自行動態申請內存的方式，同時也支持將用戶分配的隊列空間作為接口入參傳入的方式。

詳細可前往查看:

v33.xx (消息隊列篇) | 進程間如何異步解耦傳遞大數據 ?

4.共享內存(shm.c)

共享內存是進程間通信中最簡單的方式之一。共享內存允許兩個或更多進程訪問同一塊物理內存,每個進程都要單獨對這塊物理內存進行映射.當一個進程改變了這塊地址中的內容的時候，該物理頁框將被標記為臟頁,如此其它進程都會知道內容發生了更改。

這部分后系列篇內存相關篇中會重點講,內存部分雖已寫過幾篇,但是沒講透,要重新再梳理.

5.信號量(los_sem.c)

基本概念

信號量（Semaphore）是一種實現任務間通信的機制，可以實現任務間同步或共享資源的互斥訪問。 一個信號量的數據結構中，通常有一個計數值，用于對有效資源數的計數，表示剩下的可被使用的共享資源數。

對信號量有個形象的比喻 停車場的停車位, 進停車場前看下屏幕上實時顯示剩余車位,0表示不能進,只有大于0才能進入,進入后自動減1,出口處也加了監測,出去后剩余車位增加1個.

使用場景

在多任務系統中，信號量是一種非常靈活的同步方式，可以運用在多種場合中，實現鎖、同步、資源計數等功能， 也能方便的用于任務與任務，中斷與任務的同步中。常用于協助一組相互競爭的任務訪問共享資源。

詳細可前往查看:

v29.xx (信號量篇) | 信號量解決任務同步問題

6.互斥鎖 (los_mux.c) :

基本概念

互斥鎖又稱互斥型信號量，是一種特殊的二值性信號量，用于實現對臨界資源的獨占式處理。 另外，互斥鎖可以解決信號量存在的優先級翻轉問題。 任意時刻互斥鎖只有兩種狀態，開鎖或閉鎖。當任務持有時，這個任務獲得該互斥鎖的所有權， 互斥鎖處于閉鎖狀態。當該任務釋放鎖后，任務失去該互斥鎖的所有權，互斥鎖處于開鎖狀態。 當一個任務持有互斥鎖時，其他任務不能再對該互斥鎖進行開鎖或持有。

詳細可前往查看:

v27.xx (互斥鎖篇) | 互斥鎖比自旋鎖可豐滿許多

v26.xx (自旋鎖篇) | 真的好想為自旋鎖立貞節牌坊!

7.快鎖 (los_futex.c)

futex 是Fast Userspace muTexes的縮寫(快速用戶空間互斥體),是一種用戶態和內核態混合的同步機制。首先，同步的進程間通過mmap共享一段內存，futex變量就位于這段共享的內存中且操作是原子的，當進程嘗試進入互斥區或者退出互斥區的時候，先去查看共享內存中的futex變量，如果沒有競爭發生，則只修改futex,而不用再執行系統調用了。當通過訪問futex變量告訴進程有競爭發生，則還是得執行系統調用去完成相應的處理(wait 或者 wake up)。

注解版同步到官方最新源碼后,發現快鎖的部分改動很大,這部分要重新注解,敬請留意.

8.事件 (los_event.c)

基本概念事件（Event）是一種任務間通信的機制，可用于任務間的同步。

多任務環境下，任務之間往往需要同步操作，一個等待即是一個同步。事件可以提供一對多、多對多的同步操作。 一對多同步模型：一個任務等待多個事件的觸發。可以是任意一個事件發生時喚醒任務處理事件，也可以是幾個事件都發生后才喚醒任務處理事件。 多對多同步模型：多個任務等待多個事件的觸發。

事件特點

任務通過創建事件控制塊來觸發事件或等待事件。 事件間相互獨立，內部實現為一個32位無符號整型，每一位標識一種事件類型。第25位不可用，因此最多可支持31種事件類型。 事件僅用于任務間的同步，不提供數據傳輸功能。 多次向事件控制塊寫入同一事件類型，在被清零前等效于只寫入一次。 多個任務可以對同一事件進行讀寫操作。 支持事件讀寫超時機制。

事件可應用于多種任務同步場景，在某些同步場景下可替代信號量。

使用場景

隊列用于任務間通信，可以實現消息的異步處理。同時消息的發送方和接收方不需要彼此聯系，兩者間是解耦的。

詳細可前往查看:

v30.xx (事件控制篇) | 任務間多對多的同步方案

9.文件消息隊列 (hm_liteipc.c)

基于文件實現的消息隊列,特點是隊列中消息數量多(256個),傳遞消息內容大(可到1K)

#define IPC_MSG_DATA_SZ_MAX 1024	//最大的消息內容 1K ,posix最大消息內容 64個字節
#define IPC_MSG_OBJECT_NUM_MAX 256	//最大的消息數量256 ,posix最大消息數量 16個

文件消息隊列隱約感覺鴻蒙的分布式通訊,跨屏之類的功能是靠它實現的,分布式的代碼還沒研究,尚不清楚,如果有了解的請告知.后續要重點研究下跨應用通訊的技術實現.

編輯：hfy