在嵌入式系統或多工處理中，狀態機器的設計至關重要。它能有效管理系統的各種狀態及其轉換邏輯，確保系統穩定執行。本文將以交通號誌燈控制為例，深入探討狀態機器的設計模式與程式碼實作。首先，我們需要定義系統的狀態，例如紅燈、黃燈和綠燈。接著，定義觸發狀態轉換的事件，例如計時器逾時或外部指令。最後，設計狀態轉換邏輯，例如紅燈經過一段時間後轉換為綠燈，綠燈經過一段時間後轉換為黃燈，黃燈再轉換為紅燈。這樣的設計確保了交通號誌燈按照預期順序運作，並能根據實際情況調整計時時間等引數。
任務管理與排程
當你啟動電腦時，通常會開啟郵件客戶端、網頁瀏覽器和編譯器等多個程式。每個程式都在電腦上執行，似乎是平行執行的，即使你只有單核心處理器。
任務、執行緒和程式
任務、執行緒和程式這三個術語意思略有不同，但經常被交替使用。任務是處理器執行的工作。執行緒是一個任務加上一些額外的資源，如記憶體。程式通常是一個完整的執行單元，具有自己的記憶體空間，通常與其他程式分開編譯。
排程器
作業系統具有排程器，負責在活躍的程式或執行緒之間切換，以便每個程式或執行緒都能夠正常執行。有許多種實作排程器的方法，這超出了本文的範圍。關鍵點是排程器知道系統中所有需要執行的任務，並選擇哪一個任務現在應該執行。
沒有作業系統的情況
沒有作業系統的情況下，你需要自己管理任務的排程。最簡單的排程器只有一個任務。然而，當系統對環境的變化做出反應時，事情會變得更加複雜。
任務之間的通訊
按鈕按壓中斷和LED閃爍迴圈是微小系統中的兩個任務。當我們使用全域變數來指示按鈕狀態改變時，兩個任務之間就會進行通訊。然而，在任務之間分享記憶體是危險的，你需要小心地進行這種分享。
資料競爭
假設在主迴圈清除變數的同時，中斷又發生了。變數最終會是設定還是清除呢？答案取決於具體的時間順序，這種不確定性是一個大問題。如果對於一個簡單的布林值就可能這樣複雜，那麼對於需要設定兩個變數或整個資料陣列的程式碼會發生什麼呢？
資料競爭的避免
我們需要一種方法來禁止多個任務寫入同一塊記憶體。為了避免資料競爭，我們可以使用互斥鎖（mutex），它可以確保同一時間只有一個任務能夠存取分享資源。
原子操作
在沒有作業系統的情況下，當一個任務是可中斷的，但否則會一直執行直到它放棄控制時，我們需要透過停用中斷來避免資料競爭。然而，這會增加系統的延遲時間。
優先順序反轉
有些處理器允許中斷具有不同的優先順序。如果高優先順序程式因為需要低優先順序程式佔用的資源而被阻塞，同時有一個中優先順序程式開始執行，可能會阻塞低優先順序程式從而導致高優先順序程式無法及時執行。
狀態機
狀態機是一種軟體模式，它允許一個物件在其內部狀態改變時改變其行為。狀態機可以用流程圖或有限狀態自動機來表示。
狀態機範例：交通訊號控制器
交通訊號控制器是一個狀態機範例。當訊號為紅色且收到改變訊號的訊息時，它會將訊號改為綠色。當收到停止訊號時，它會先將訊號改為黃色一段時間，然後再改為紅色。
狀態機實作
實作狀態機需要確定系統的狀態和可能觸發狀態改變的事件。然後，根據這些狀態和事件來設計狀態轉換邏輯。
狀態機器的應用：交通訊號燈控制
在軟體開發中，狀態機器是一種常見的設計模式，尤其是在需要處理不同狀態和事件的系統中。下面，我們將以交通訊號燈控制為例，展示如何使用狀態機器來實作這種控制。
狀態機器的基本結構
狀態機器的基本結構包括以下幾個部分：
- 狀態（State）：系統可以處於的不同狀態。在交通訊號燈控制中，狀態可以是紅燈、黃燈或綠燈。
- 事件（Event）：觸發狀態轉換的事件。在這個例子中，事件可以是計時器過期（timer expired）或去命令（go command）。
- 轉換（Transition）：當事件發生時，從一個狀態轉換到另一個狀態的過程。
實作交通訊號燈控制的狀態機器
以下是交通訊號燈控制狀態機器的實作：
stateDiagram-v2
[*] --> 綠燈
綠燈 --> 黃燈 : 計時器過期
黃燈 --> 紅燈 : 計時器過期
紅燈 --> 綠燈 : 去命令
在這個狀態機器中，我們定義了三個狀態：綠燈、黃燈和紅燈。轉換條件如下：
- 當綠燈的計時器過期時，轉換到黃燈。
- 當黃燈的計時器過期時，轉換到紅燈。
- 當收到去命令時，從紅燈轉換到綠燈。
狀態機器的程式碼實作
以下是使用C++實作的交通訊號燈控制狀態機器的簡單示例：
enum class State { GREEN, YELLOW, RED };
class TrafficLight {
public:
TrafficLight() : state_(State::GREEN) {}
void timerExpired() {
switch (state_) {
case State::GREEN:
state_ = State::YELLOW;
break;
case State::YELLOW:
state_ = State::RED;
break;
case State::RED:
// 不進行轉換
break;
}
}
void goCommand() {
if (state_ == State::RED) {
state_ = State::GREEN;
}
}
State getState() const { return state_; }
private:
State state_;
};
在這個示例中，TrafficLight類別使用一個列舉State來代表不同的狀態。timerExpired函式根據當前的狀態進行轉換，而goCommand函式則根據當前的狀態決定是否轉換到綠燈。
內容解密：
- 狀態機器是一種軟體設計模式，尤其適用於需要處理不同狀態和事件的系統。
- 交通訊號燈控制可以使用狀態機器來實作，定義不同的狀態（綠燈、黃燈、紅燈）和轉換條件（計時器過期、去命令）。
- 狀態機器的實作可以使用列舉來代表不同的狀態，並根據事件進行轉換。
圖表翻譯：
flowchart TD
A[初始狀態] --> B[綠燈]
B --> C[黃燈] : 計時器過期
C --> D[紅燈] : 計時器過期
D --> B : 去命令
這個流程圖展示了交通訊號燈控制狀態機器的轉換過程。從初始狀態開始，系統進入綠燈狀態，當計時器過期時轉換到黃燈，然後再轉換到紅燈。當收到去命令時，系統從紅燈轉換回綠燈。
狀態機器的設計與實作
在軟體開發中，狀態機器是一種常見的設計模式，用於管理複雜的狀態轉換和事件處理。狀態機器可以根據不同的事件和條件，切換到不同的狀態，並執行相應的動作。
狀態機器的基本概念
狀態機器由三個基本部分組成：狀態、事件和轉換。狀態是系統的當前狀態，事件是觸發狀態轉換的觸發器，轉換是從一個狀態到另一個狀態的過程。
狀態機器的設計模式
有兩種常見的狀態機器設計模式：狀態中心設計模式和轉換中心設計模式。
狀態中心設計模式
在狀態中心設計模式中，每個狀態都需要知道其它狀態的存在和轉換條件。這種設計模式簡單易懂，但可能導致狀態之間的耦合度過高。
轉換中心設計模式
在轉換中心設計模式中，狀態轉換的資訊被分離出來，形成了一個獨立的轉換函式。這種設計模式更為封裝，減少了狀態之間的耦合度。
狀態機器的實作
狀態機器可以透過多種方式實作，包括使用 switch 陳述式、使用查表法等。在以下的例子中，我們使用 switch 陳述式來實作一個簡單的狀態機器。
例子：交通訊號燈
假設我們要實作一個交通訊號燈的狀態機器，該訊號燈有三個狀態：紅燈、黃燈和綠燈。每個狀態都需要根據不同的事件進行轉換。
flowchart TD
A[紅燈] -->|停|> B[黃燈]
B -->|停|> C[綠燈]
C -->|停|> A
狀態中心設計模式實作
在狀態中心設計模式中，每個狀態都需要知道其它狀態的存在和轉換條件。
void redLight() {
// 執行紅燈動作
if (event == STOP) {
// 轉換到黃燈
yellowLight();
}
}
void yellowLight() {
// 執行黃燈動作
if (event == STOP) {
// 轉換到綠燈
greenLight();
}
}
void greenLight() {
// 執行綠燈動作
if (event == STOP) {
// 轉換到紅燈
redLight();
}
}
轉換中心設計模式實作
在轉換中心設計模式中，狀態轉換的資訊被分離出來，形成了一個獨立的轉換函式。
void nextState() {
switch (state) {
case RED:
state = YELLOW;
break;
case YELLOW:
state = GREEN;
break;
case GREEN:
state = RED;
break;
}
}
void redLight() {
// 執行紅燈動作
if (event == STOP) {
nextState();
}
}
void yellowLight() {
// 執行黃燈動作
if (event == STOP) {
nextState();
}
}
void greenLight() {
// 執行綠燈動作
if (event == STOP) {
nextState();
}
}
圖表翻譯：
上述Mermaid圖表描述了一個簡單的交通訊號燈的狀態機器，該訊號燈有三個狀態：紅燈、黃燈和綠燈。每個狀態都需要根據不同的事件進行轉換。圖表展示了狀態之間的轉換關係，紅燈轉換到黃燈，黃燈轉換到綠燈，綠燈轉換到紅燈。
狀態機器實作方法
在實作狀態機器時，有多種方法可以選擇。以下將介紹兩種常見的實作方法：狀態中心狀態機器（State-Centric State Machine）和事件中心狀態機器（Event-Centric State Machine）。
狀態中心狀態機器
在這種實作方法中，狀態機器的狀態和轉換是分開的。每個狀態都有一個對應的函式，負責處理狀態的轉換。例如：
switch (state) {
case RED_LIGHT:
// 處理紅燈狀態
break;
case GREEN_LIGHT:
// 處理綠燈狀態
break;
}
這種方法的優點是，可以將狀態和轉換分開，易於維護和修改。但是，如果狀態轉換依賴於事件，則可能需要額外的邏輯來處理。
事件中心狀態機器
在這種實作方法中，每個事件都有一個對應的函式，負責處理狀態的轉換。例如：
switch (event) {
case STOP:
if (state == GREEN_LIGHT) {
// 處理停止事件
}
break;
}
這種方法的優點是，可以將事件和狀態轉換分開，易於維護和修改。但是，可能需要額外的邏輯來處理狀態轉換。
狀態模式
另一種實作狀態機器的方法是使用狀態模式（State Pattern）。在這種方法中，每個狀態都是一個物件，具有自己的方法來處理事件。例如：
class RedLightState {
void enter() {
// 處理紅燈狀態
}
void exit() {
// 處理離開紅燈狀態
}
void handleGoEvent() {
// 處理 go 事件
}
void handleStopEvent() {
// 處理 stop 事件
}
}
這種方法的優點是，可以將狀態和事件處理分開，易於維護和修改。但是，可能需要額外的邏輯來處理狀態轉換。
內容解密：
- 狀態中心狀態機器：每個狀態都有一個對應的函式，負責處理狀態的轉換。
- 事件中心狀態機器：每個事件都有一個對應的函式，負責處理狀態的轉換。
- 狀態模式：每個狀態都是一個物件，具有自己的方法來處理事件。
圖表翻譯：
flowchart TD
A[紅燈] --> B[綠燈]
B --> C[黃燈]
C --> A
此圖表示了一個簡單的交通燈狀態機器。紅燈、綠燈和黃燈都是不同的狀態，之間可以進行轉換。
狀態機器的實作和應用
狀態機器是一種可以根據狀態和事件進行轉換的系統。它可以用於管理複雜的行為和控制流程。在本文中，我們將探討狀態機器的實作和應用。
從底層實作到高階應用的全面檢視顯示，狀態機器的設計模式在嵌入式系統和軟體開發中扮演著至關重要的角色。透過多維比較分析，狀態機器的結構化方法有效地簡化了複雜系統的設計和維護，尤其在處理多狀態和事件驅動的系統中，相較於傳統的條件判斷式程式碼，狀態機器更具備清晰的邏輯和可讀性，降低了程式碼的複雜度和出錯機率。然而，狀態機器的設計也存在一些限制。例如，在狀態數量龐大且轉換邏輯複雜的情況下，狀態機器的設計和維護成本可能會提高。對於此類別情境，建議採用狀態模式或層次狀態機等更進階的設計技巧，並搭配視覺化工具輔助設計和除錯。此外，在實務落地分析中，開發者需要審慎評估系統的規模和複雜度，選擇合適的狀態機器實作方式，例如狀態中心或事件中心模式。同時，應注意避免狀態爆炸和優先順序反轉等潛在問題。展望未來，隨著系統複雜性的提升和事件驅動架構的普及，預計狀態機器將在更多領域得到廣泛應用，例如物聯網、人工智慧和自動駕駛等。玄貓認為，深入理解狀態機器的設計原則和最佳實踐，對於構建穩健、可維護和高效的軟體系統至關重要。對於追求程式碼品質和系統穩定性的開發團隊而言，採用狀態機器無疑是一項值得投資的技術策略。
