最簡單的做法是將所有主動物件配置給同一個執行緒或程序,並使用簡單的主動物件排程器,因為這樣可以降低環境定義切換的額外負荷。不過,在某些情況下,可能需要將主動物件分散到一或多個執行緒或程序。大部分的即時系統都是屬於這種情況,因為即時系統會使用封裝體來代表
有時必須符合硬性排程需求的邏輯執行緒。
如果和主動物件共用同一個作業系統執行緒的其他主動物件對其他程序或執行緒進行同步呼叫,並且此呼叫封鎖住啟動物件的共用作業系統執行緒時,此狀況就會自動暫停位於啟動程序中的所有其他主動物件。現在情況並不一定要像這樣:對主動物件而言是同步的呼叫,對控制主動物件群組的簡單排程器而言,卻可能是以非同步式處理
- 因此排程器會暫停主動物件進行呼叫(等候其同步呼叫完成),然後再排定執行其他主動物件。
當原始的「同步」作業完成時,就可以回復呼叫主動物件。不過,這種方式並不一定永遠可行,這是因為排程器可能無法設計為在進行封鎖之前,截取所有同步呼叫。請注意,在使用相同的作業系統程序或執行緒的主動物件之間起始的同步呼叫,為了通用起見,可以由排程器用這種方式處理
- 對於啟動主動物件而言,其效果等於程序呼叫。
因此我們可以將此歸納為主動物件應該依據它們是否需要和封鎖執行緒的同步呼叫作業平行執行,來加以分組程序和執行緒。亦即,主動物件應該和會使用同步呼叫來封鎖執行緒的
其他物件相同的程序和執行緒唯一狀況,是主動物件不需要和該物件同時執行,並且可以接受當其他物件被封鎖時,它自己被禁止執行。在回應極為重要的特別情況中,這種情況會導致需要針對每個主動物件使用個別的執行緒或程序。
在即時系統中,封裝體的訊息型介面代表對於跨封裝體的通訊而言,較簡單的做法是建立一個排程器,來確保即使封裝體在和其他封裝體進行同步通訊時,作業系統執行緒也絕不會被鎖定。不過,封裝體還是可以直接向作業系統發出要求,例如,針對同步計時等待,因而封鎖執行緒。因此,如果封裝體要共用相同執行緒
(並使用簡單的排程器來模擬平行作業)時,就需要針對封裝體啟動的低階服務建立一個使用慣例,來避免這種行為。
就一般的規則而言,在上述情況中,最好能使用輕型緒,而不要使用完整的程序,因為輕型緒的額外負荷較小。不過,您可能還是希望能利用到程序在一些特殊情況下的某些特殊特質的優點。由於執行緒會共用相同的位址空間,因此它們的潛在風險比程序高。如果有意外改寫的顧慮存在的話,則最好使用程序。此外,由於在大部分作業系統中,程序是代表獨立的回復單元,因此最好能依據物件是否需要分別回復,來配置主動物件給程序。亦即,需要作為同一單元回復的所有主動物件,可以包裝在同一個程序中。
針對系統需要的每個個別的控制流程,建立一個程序或執行緒(輕型程序)。在需要巢狀的控制流程(例如在程序中,在子作業層次需要獨立的控制流程)時,就應該使用執行緒。
例如,個別的控制緒可能需要執行下列動作:
-
不同的軟體部分有不同的問題
-
善用同一節點的多個 CPU 以及分散式系統中的多個節點好處
-
當控制緒被暫停時,配置循環至其他活動以提高 CPU 使用率
-
決定活動優先順序
-
支援將負荷分攤到數個程序和處理器
-
採用備份程序,達到更高層的系統可用性
-
支援 DBMS、「交易管理程式」或其他主要子系統。
範例
在「自動提款機」中,必須處理的非同步事件是來自三個不同的來源:系統的使用者、ATM 裝置(例如,如果現金輸送匣卡住時)或是 ATM 網路 (例如來自網路的關閉指示)。為了處理這些非同步事件,我們可以如以下所示,使用 UML
內的主動類別,在 ATM 中定義三個不同的執行緒。
ATM 中的程序與執行緒
|