【TencentOS tiny】深度源碼分析（7）——事件
- 2019 年 10 月 16 日
- 筆記
引言
大家在裸機編程中很可能經常用到flag這種變數，用來標誌一下某個事件的發生，然後在循環中判斷這些標誌是否發生，如果是等待多個事件的話，還可能會if((xxx_flag)&&(xxx_flag))這樣子做判斷。當然，如果聰明一點的同學就會拿flag的某些位做標誌，比如這個變數的第一位表示A事件，第二位表示B事件，當這兩個事件都發生的時候，就判斷flag&0x03的值是多少，從而判斷出哪個事件發生了。
但在作業系統中又將如何實現呢？
事件
在作業系統中，事件是一種內核資源，主要用於任務與任務間、中斷與任務間的同步，不提供數據傳輸功能！
與使用訊號量同步有細微的差別：事件它可以實現一對多，多對多的同步。即一個任務可以等待多個事件的發生：可以是任意一個事件發生時喚醒任務進行事件處理；也可以是幾個事件都發生後才喚醒任務進行事件處理。同樣，也可以是多個任務同步多個事件。
每一個事件組只需要極少的RAM空間來保存事件旗標，一個事件（控制塊）中包含了一個旗標，這個旗標的每一位表示一個「事件」，旗標存儲在一個k_event_flag_t類型的變數中（名字叫flag，旗標簡單理解就是事件標記變數），該變數在事件控制塊中被定義，每一位代表一個事件，任務通過「邏輯與」或「邏輯或」與一個或多個事件建立關聯，在事件發生時任務將被喚醒。
-
事件「邏輯或」是
獨立型同步，指的是任務所等待的若干事件中任意一個事件發生即可被喚醒； -
事件「邏輯與」則是
關聯型同步，指的是任務所等待的若干事件中全部都發生時才被喚醒。
事件是一種實現任務間通訊的機制，可用於實現任務間的同步，但事件無數據傳輸。多任務環境下，任務、中斷之間往往需要同步操作，一個事件發生會告知等待中的任務，即形成一個任務與任務、中斷與任務間的同步。
事件無排隊性，即多次向任務設置同一事件(如果任務還未來得及讀走)，等效於只設置一次。
此外事件可以提供一對多、多對多的同步操作。
-
一對多同步模型：一個任務等待多個事件的觸發，這種情況是比較常見的； -
多對多同步模型：多個任務等待多個事件的觸發，任務可以通過設置事件位來實現事件的觸發和等待操作。
事件數據結構
事件控制塊
TencentOS tiny 通過事件控制塊操作事件，其數據類型為k_event_t，事件控制塊由多個元素組成。
pend_obj有點類似於面向對象的繼承，繼承一些屬性，裡面有描述內核資源的類型（如互斥鎖、隊列、互斥量等，同時還有一個等待列表list）。flag是旗標，一個32位的變數，因此每個事件控制塊最多只能標識32個事件發生！
typedef struct k_event_st { pend_obj_t pend_obj; k_event_flag_t flag; } k_event_t;任務控制塊與事件相關的數據結構
typedef struct k_task_st { ··· k_opt_t opt_event_pend; /**< 等待事件的的操作類型：TOS_OPT_EVENT_PEND_ANY 、 TOS_OPT_EVENT_PEND_ALL */ k_event_flag_t flag_expect; /**< 期待發生的事件 */ k_event_flag_t *flag_match; /**< 等待到的事件（匹配的事件） */ ··· } k_task_t;與事件相關的宏定義
在tos_config.h中，配置事件開關的宏定義是TOS_CFG_EVENT_EN
#define TOS_CFG_EVENT_EN 1u在tos_event.h中，存在一些宏定義是用於操作事件的（opt選項）：
// if we are pending an event, for any flag we expect is set is ok, this flag should be passed to tos_event_pend #define TOS_OPT_EVENT_PEND_ANY (k_opt_t)0x0001 // if we are pending an event, must all the flag we expect is set is ok, this flag should be passed to tos_event_pend #define TOS_OPT_EVENT_PEND_ALL (k_opt_t)0x0002 #define TOS_OPT_EVENT_PEND_CLR (k_opt_t)0x0004TOS_OPT_EVENT_PEND_ANY：任務在等待任意一個事件發生，即「邏輯或」！TOS_OPT_EVENT_PEND_ALL：任務在等待所有事件發生，即「邏輯與」！TOS_OPT_EVENT_PEND_CLR：清除等待到的事件旗標，可以與TOS_OPT_EVENT_PEND_ANY、TOS_OPT_EVENT_PEND_ALL混合使用（通過「|」運算符）。
除此之外還有一個枚舉類型的數據結構，用於發送事件時的選項操作，可以在發送事件時清除事件旗標的其他位（即覆蓋，影響其他事件），也可以保持原本旗標中的其他位（不覆蓋，不影響其他事件）。
typedef enum opt_event_post_en { OPT_EVENT_POST_KEP, OPT_EVENT_POST_CLR, } opt_event_post_t;創建事件
系統中每個事件都有對應的事件控制塊，事件控制塊中包含了事件的所有資訊，比如它的等待列表、它的資源類型，以及它的事件旗標值，那麼可以想像一下，創建事件的本質是不是就是對事件控制塊進行初始化呢？很顯然就是這樣子的。因為在後續對事件的操作都是通過事件控制塊來操作的，如果控制塊沒有資訊，那怎麼能操作嘛~
創建事件函數是tos_event_create()，傳入一個事件控制塊的指針*event，除此之外還可以指定事件初始值init_flag。
事件的創建實際上就是調用pend_object_init()函數將事件控制塊中的event->pend_obj成員變數進行初始化，它的資源類型被標識為PEND_TYPE_EVENT。然後將event->flag成員變數設置為事件旗標初始值init_flag。
__API__ k_err_t tos_event_create(k_event_t *event, k_event_flag_t init_flag) { TOS_PTR_SANITY_CHECK(event); pend_object_init(&event->pend_obj, PEND_TYPE_EVENT); event->flag = init_flag; return K_ERR_NONE; }銷毀事件
事件銷毀函數是根據事件控制塊直接銷毀的，銷毀之後事件的所有資訊都會被清除，而且不能再次使用這個事件，當事件被銷毀時，其等待列表中存在任務，系統有必要將這些等待這些任務喚醒，並告知任務事件已經被銷毀了PEND_STATE_DESTROY。然後產生一次任務調度以切換到最高優先順序任務執行。
TencentOS tiny 對事件銷毀的處理流程如下：
- 調用
pend_is_nopending()函數判斷一下是否有任務在等待事件 - 如果有任務在等待事件則調用
pend_wakeup_all()函數將這些任務喚醒，並且告知等待任務事件已經被銷毀了（即設置任務控制塊中的等待狀態成員變數pend_state為PEND_STATE_DESTROY）。 - 調用
pend_object_deinit()函數將事件控制塊中的內容清除，最主要的是將控制塊中的資源類型設置為PEND_TYPE_NONE，這樣子就無法使用這個事件了。 - 將
event->flag成員變數恢復為默認值0。 - 進行任務調度
knl_sched()
注意：如果事件控制塊的RAM是由編譯器靜態分配的，所以即使是銷毀了事件，這個記憶體也是沒辦法釋放的。當然你也可以使用動態記憶體為事件控制塊分配記憶體，只不過在銷毀後要將這個記憶體釋放掉，避免記憶體泄漏。
__API__ k_err_t tos_event_destroy(k_event_t *event) { TOS_CPU_CPSR_ALLOC(); TOS_PTR_SANITY_CHECK(event); #if TOS_CFG_OBJECT_VERIFY_EN > 0u if (!pend_object_verify(&event->pend_obj, PEND_TYPE_EVENT)) { return K_ERR_OBJ_INVALID; } #endif TOS_CPU_INT_DISABLE(); if (!pend_is_nopending(&event->pend_obj)) { pend_wakeup_all(&event->pend_obj, PEND_STATE_DESTROY); } pend_object_deinit(&event->pend_obj); event->flag = (k_event_flag_t)0u; TOS_CPU_INT_ENABLE(); knl_sched(); return K_ERR_NONE; }等待事件
tos_event_pend()函數用於獲取事件，通過這個函數，就可以知道事件旗標中的哪一位被置1，即哪一個事件發生了，然後任務可以對等待的事件指定「邏輯與」、「邏輯或」進行等待操作（opt_pend選項）。
並且這個函數實現了等待超時機制，且僅當任務等待的事件發生時，任務才能等待到事件。當事件未發生的時候，等待事件的任務會進入阻塞態，阻塞時間timeout由用戶指定，在這段時間中，如果事件一直沒發生，該任務將保持阻塞狀態以等待事件發生。當其它任務或中斷服務程式往其等待的事件旗標設置對應的標誌位，該任務將自動由阻塞態轉為就緒態。當任務等待的時間超過了指定的阻塞時間，即使事件還未發生，任務也會自動從阻塞態轉移為就緒態。這樣子很有效的體現了作業系統的實時性。
任務獲取了某個事件時，可以選擇清除事件操作。
等待事件的操作不允許在中斷上下文環境運行！
等待事件的過程如下：
- 首先檢測傳入的參數是否正確。，注意
opt_pend的選項必須存在TOS_OPT_EVENT_PEND_ALL或者TOS_OPT_EVENT_PEND_ANY之一，且二者不允許同時存在（互斥）。 - 調用
event_is_match()函數判斷等待的事件是否已發生（即任務等待的事件與事件控制塊中的旗標是否匹配）。 - 在
event_is_match()函數中會根據等待選項opt_pend是等待任意一個事件（TOS_OPT_EVENT_PEND_ANY）還是等待所有事件（TOS_OPT_EVENT_PEND_ANY）做出是否匹配的判斷，如果是匹配了則返回K_TRUE，反之返回K_FALSE，同時等待到的事件通過flag_match變數返回（已發生匹配）。對於等待所有時間的選項，當且僅當所有事件都發生是才算匹配：(event & flag_expect) == flag_expect)，對於等待任意一個事件的選項，有其中一個事件發生都算匹配：(event & flag_expect)。 - 如果事件未發生則可能會阻塞當前獲取的任務，看一下用戶指定的阻塞時間
timeout是否為不阻塞TOS_TIME_NOWAIT，如果不阻塞則直接返回K_ERR_PEND_NOWAIT錯誤程式碼。 - 如果調度器被鎖了
knl_is_sched_locked()，則無法進行等待操作，返回錯誤程式碼K_ERR_PEND_SCHED_LOCKED，畢竟需要切換任務，調度器被鎖則無法切換任務。 - 將任務控制塊中關於事件的變數設置一下，即設置任務期望等待的事件
k_curr_task->flag_expect，任務匹配的事件k_curr_task->flag_match，以及任務等待事件的選項k_curr_task->opt_event_pend。 - 調用
pend_task_block()函數將任務阻塞，該函數實際上就是將任務從就緒列表中移除k_rdyq.task_list_head[task_prio]，並且插入到等待列表中object->list，如果等待的時間不是永久等待TOS_TIME_FOREVER，還會將任務插入時間列表中k_tick_list，阻塞時間為timeout，然後進行一次任務調度knl_sched()。 - 當程式能繼續往下執行時，則表示
任務等待到事件，又或者等待發生了超時，任務就不需要等待事件了，此時將任務控制塊中的內容清空，即清空任務期望等待的事件k_curr_task->flag_expect，任務匹配的事件k_curr_task->flag_match，以及任務等待事件的選項k_curr_task->opt_event_pend，同時還調用pend_state2errno()函數獲取一下任務的等待狀態，看一下是哪種情況導致任務恢復運行，並且將結果返回給調用等待事件函數的任務。
注意：當等待事件的任務能從阻塞中恢復運行，也不一定是等待到事件發生，也有可能是發生了超時，因此在寫程式的時候必須要判斷一下等待的事件狀態，如果是K_ERR_NONE則表示獲取成功！
程式碼如下：
__STATIC__ int event_is_match(k_event_flag_t event, k_event_flag_t flag_expect, k_event_flag_t *flag_match, k_opt_t opt_pend) { if (opt_pend & TOS_OPT_EVENT_PEND_ALL) { if ((event & flag_expect) == flag_expect) { *flag_match = flag_expect; return K_TRUE; } } else if (opt_pend & TOS_OPT_EVENT_PEND_ANY) { if (event & flag_expect) { *flag_match = event & flag_expect; return K_TRUE; } } return K_FALSE; } __API__ k_err_t tos_event_pend(k_event_t *event, k_event_flag_t flag_expect, k_event_flag_t *flag_match, k_tick_t timeout, k_opt_t opt_pend) { TOS_CPU_CPSR_ALLOC(); TOS_PTR_SANITY_CHECK(event); TOS_PTR_SANITY_CHECK(flag_match); TOS_IN_IRQ_CHECK(); #if TOS_CFG_OBJECT_VERIFY_EN > 0u if (!pend_object_verify(&event->pend_obj, PEND_TYPE_EVENT)) { return K_ERR_OBJ_INVALID; } #endif if (!(opt_pend & TOS_OPT_EVENT_PEND_ALL) && !(opt_pend & TOS_OPT_EVENT_PEND_ANY)) { return K_ERR_EVENT_PEND_OPT_INVALID; } if ((opt_pend & TOS_OPT_EVENT_PEND_ALL) && (opt_pend & TOS_OPT_EVENT_PEND_ANY)) { return K_ERR_EVENT_PEND_OPT_INVALID; } TOS_CPU_INT_DISABLE(); if (event_is_match(event->flag, flag_expect, flag_match, opt_pend)) { if (opt_pend & TOS_OPT_EVENT_PEND_CLR) { // destroy the bridge after get across the river event->flag = (k_event_flag_t)0u; } TOS_CPU_INT_ENABLE(); return K_ERR_NONE; } if (timeout == TOS_TIME_NOWAIT) { TOS_CPU_INT_ENABLE(); return K_ERR_PEND_NOWAIT; } if (knl_is_sched_locked()) { TOS_CPU_INT_ENABLE(); return K_ERR_PEND_SCHED_LOCKED; } k_curr_task->flag_expect = flag_expect; k_curr_task->flag_match = flag_match; k_curr_task->opt_event_pend = opt_pend; pend_task_block(k_curr_task, &event->pend_obj, timeout); TOS_CPU_INT_ENABLE(); knl_sched(); k_curr_task->flag_expect = (k_event_flag_t)0u; k_curr_task->flag_match = (k_event_flag_t *)K_NULL; k_curr_task->opt_event_pend = (k_opt_t)0u; return pend_state2errno(k_curr_task->pend_state); }發送事件
TencentOS tiny 提供兩個函數發送事件，分別是：tos_event_post()與tos_event_post_keep()，兩個函數本質上都是調用同一個函數event_do_post()去實現發送事件的操作的，只不過選項是不同而已，使用tos_event_post()函數會覆蓋寫入指定的事件，可能影響其他已發生的事件，而tos_event_post_keep()函數則可以保持其他事件位不改變的同時發生事件，在實際情況中後者更常用。
此函數用於將已發生的事件寫入事件旗標中指定的位，當對應的位被置1之後，等待事件的任務將可能被恢復，此時需要遍歷等待在事件對象上的事件等待列表，判斷是否有任務期望的事件與當前事件旗標的值匹配，如果有，則喚醒該任務。
簡單來說，就是設置自己定義的事件標誌位為1，並且看看有沒有任務在等待這個事件，有的話就喚醒它。
TencentOS tiny 中設計的很好的地方就是簡單與低耦合，這兩個api介面本質上都是調用event_do_post()函數去發生事件，只是通過opt_post參數不同選擇不同的處理方法。
在event_do_post()函數中的處理也是非常簡單明了的，其執行思路如下：
- 首先判斷一下發生事件的方式
opt_post，如果是OPT_EVENT_POST_KEP則採用或運算「|」寫入事件旗標，否則直接賦值。 - 使用
TOS_LIST_FOR_EACH_SAFE遍歷等待在事件對象上的事件等待列表，通過event_is_match()函數判斷是否有任務期望的事件與當前事件旗標的值匹配，如果有則調用pend_task_wakeup()函數喚醒對應的任務。 - 如果喚醒的等待任務指定了清除對應的事件，那麼將清除事件的旗標值。
- 最後進行一次任務調度
knl_sched()。
__STATIC__ k_err_t event_do_post(k_event_t *event, k_event_flag_t flag, opt_event_post_t opt_post) { TOS_CPU_CPSR_ALLOC(); k_task_t *task; k_list_t *curr, *next; #if TOS_CFG_OBJECT_VERIFY_EN > 0u if (!pend_object_verify(&event->pend_obj, PEND_TYPE_EVENT)) { return K_ERR_OBJ_INVALID; } #endif if (opt_post == OPT_EVENT_POST_KEP) { event->flag |= flag; } else { event->flag = flag; } TOS_CPU_INT_DISABLE(); TOS_LIST_FOR_EACH_SAFE(curr, next, &event->pend_obj.list) { task = TOS_LIST_ENTRY(curr, k_task_t, pend_list); if (event_is_match(event->flag, task->flag_expect, task->flag_match, task->opt_event_pend)) { pend_task_wakeup(TOS_LIST_ENTRY(curr, k_task_t, pend_list), PEND_STATE_POST); // if anyone pending the event has set the TOS_OPT_EVENT_PEND_CLR, then no wakeup for the others pendig for the event. if (task->opt_event_pend & TOS_OPT_EVENT_PEND_CLR) { event->flag = (k_event_flag_t)0u; break; } } } TOS_CPU_INT_ENABLE(); knl_sched(); return K_ERR_NONE; } __API__ k_err_t tos_event_post(k_event_t *event, k_event_flag_t flag) { TOS_PTR_SANITY_CHECK(event); return event_do_post(event, flag, OPT_EVENT_POST_CLR); } __API__ k_err_t tos_event_post_keep(k_event_t *event, k_event_flag_t flag) { TOS_PTR_SANITY_CHECK(event); return event_do_post(event, flag, OPT_EVENT_POST_KEP); }喜歡就關注我吧！
相關程式碼可以在公眾號後台回復 「 19 」 獲取。
更多資料歡迎關注「物聯網IoT開發」公眾號！
