多重處理程序之溝通機制

在多重處理程序的溝通機制中，最重要的目的有二：(1)讓多個處理程序可 以做資料交換與資源共享、(2)讓處理程序之間可以同步。在Linux的作業系統中 一共提供三種處理程序之間的溝通機制(inter-process communication, IPC) [42]：(1) 訊 息 佇 列(message queue) 、 (2) 信 號 (semaphore) 以 及 (3) 共 享 記 憶 體 (shared memory)。分別簡述如下：

(1) 訊息佇列(message queue)：

訊息佇列可以視為一些訊息的組合，這些訊息都位於核心程式中，彼此以鏈 結串列(linked list)的方式連結，而每個訊息佇列都要透過辨識元來辨識。佇列裡 的每筆訊息都有一個型別為長整數(long int)的欄位，一個非負值的訊息長度，和 一個真正的資料長度(這個是跟訊息長度一致)，當要傳送訊息到一個佇列時，必 須把這些值指定給msgsnd函式。若要從訊息佇列裡讀取訊息則需呼叫msgrcv函 式，在讀取時不一定需要使用先進先出的順序來讀取這些資料，也可以根據這些 訊息的種類來讀取。在實際上使用發現這個機制並不會比其他的IPC快，所以，

這種IPC不夠實用。

(2) 信號(semaphore)：

信號與一般的IPC機制不太一樣，實際上，信號是一個計數器，它用來讓數 個處理程序可以共同讀取一個讓大家分享的資料物件。其使用方法如下：

(a) 先測試控制這個資源的信號。

(3) 共享記憶體(shared memory)：

共享記憶體可以讓兩個以上的處理程序來分享同一塊記憶體，這是一種速度

能不用信號這個機制就盡量少用。所以，我們並不使用信號這個同步機 制，而是提出兩種高效率的方法來解決這方面的問題：(a)取代同步機制 之溝通機制、(b)仲裁機制。

如圖3.10所示，處理程序A會對記憶體做寫入的動作，而處理程序 B則會對記憶體做讀取的動作。使用同步機制的方法就如圖4.10中的(a) 所示，當處理程序A寫滿記憶體時會告知處理程序B使其開始做讀取的 動作，而當處理程序B做完讀取的動作後，再告知處理程序A，使其繼 續做寫入的動作，因此在這樣的機制下，當處理程序B在工作時，A是 不能動作的。如此一來，這兩個處理程序並無法同時進行，而這也違背 了我們要作多工排程的目的。

圖3.10、記憶體運用說明圖

因此，我們使用另一種方法解決這個問題。如圖4.10中的(b)所示，

我們呼叫了兩塊相同大小的記憶體，當處理程序A寫入資料至記憶體M1 時，處理程序B對記憶體M2做讀取的動作。當處理程序都完成工作後再 交換，由處理程序A寫入資料至M2時，處理程序B去讀取M1的資料。

如此一來，便能讓這兩個程序同時動作並減少一些同步機制的控制與處 理程序等待的時間，但缺點是需要以空間換取時間。根據我們對時間上 的要求以及ARM上所能支配的記憶體，我們選擇使用這個方法來減少 同步機制的使用，以避免在同步時會有一些等待的時間浪費。

(b) 仲裁機制：

在可以避免使用信號的情況中，我們利用上述的方法來解決，但 是，還是有許多狀況勢必需要用同步機制的，例如：某些處理程序必須

等待另一個處理程序處理完，才能再繼續執行。此時，就必須使用同步

™ bit3：這個bit就是聯結DSP相關程式與一般周邊介面控制程 式，這個bit將會驅動DSP的程式，使其開始做運算。

表 3.1、 旗 標 對 照 表

(c) 共享記憶體：

在資料傳送至 IPBUF 這個程序中，就必須要先取得從無線模組接 收到的資料，此時就必須要能傳遞大量資料的溝通機制。在溝通機制中 較常用的有訊息佇列與共享記憶體兩種，而本論文使用共享記憶體來實 現溝通機制，主要原因有以下兩點：

™ 由於所需要的通訊的資料是一大塊記憶體，為了避免浪費一些 記憶體搬移的動作。

™ 在 IPC 的機制中，共享記憶體是最快的一種。

所以，我們使用共享記憶體的方式，直接取用另外一個程序中的記 憶體。由於共享記憶體的使用會需要使用到全域變數的使用，但在ARM 上全域變數很容易被污染，所以，所以非必要不要使用共享記憶體，而 在使用的同時也必須小心使用，避免受到全域變數污染問題的影響。如 圖 3.11 所示，我們一共宣告了五個共享記憶體的區塊，以下分別針對 這五塊共享記憶體做一簡介：

圖3.11、共享記憶體連接示意圖

™ EEG 原始資料：