【TencentOS tiny】深度源碼分析（7）——事件

時間  2019-11-08
標籤 TencentOS tiny 深度 源碼 分析 事件 简体版
原文   原文鏈接

引言

你們在裸機編程中極可能常常用到flag這種變量，用來標誌一下某個事件的發生，而後在循環中判斷這些標誌是否發生，若是是等待多個事件的話，還可能會if((xxx_flag)&&(xxx_flag))這樣子作判斷。固然，若是聰明一點的同窗就會拿flag的某些位作標誌，好比這個變量的第一位表示A事件，第二位表示B事件，當這兩個事件都發生的時候，就判斷flag&0x03的值是多少，從而判斷出哪一個事件發生了。編程

但在操做系統中又將如何實現呢？api

事件

在操做系統中，事件是一種內核資源，主要用於任務與任務間、中斷與任務間的同步，不提供數據傳輸功能！數據結構

與使用信號量同步有細微的差異：事件它能夠實現一對多，多對多的同步。即一個任務能夠等待多個事件的發生：能夠是任意一個事件發生時喚醒任務進行事件處理；也能夠是幾個事件都發生後才喚醒任務進行事件處理。一樣，也能夠是多個任務同步多個事件。函數

每個事件組只須要極少的RAM空間來保存事件旗標，一個事件（控制塊）中包含了一個旗標，這個旗標的每一位表示一個「事件」，旗標存儲在一個k_event_flag_t類型的變量中（名字叫flag，旗標簡單理解就是事件標記變量），該變量在事件控制塊中被定義，每一位表明一個事件，任務經過「邏輯與」或「邏輯或」與一個或多個事件創建關聯，在事件發生時任務將被喚醒。post

  • 事件「邏輯或」是獨立型同步，指的是任務所等待的若干事件中任意一個事件發生便可被喚醒；
    • 事件「邏輯與」則是關聯型同步，指的是任務所等待的若干事件中所有都發生時才被喚醒。

事件是一種實現任務間通訊的機制，可用於實現任務間的同步，但事件無數據傳輸。多任務環境下，任務、中斷之間每每須要同步操做，一個事件發生會告知等待中的任務，即造成一個任務與任務、中斷與任務間的同步。this

事件無排隊性，即屢次向任務設置同一事件(若是任務還將來得及讀走)，等效於只設置一次。spa

此外事件能夠提供一對多、多對多的同步操做。操作系統

  • 一對多同步模型：一個任務等待多個事件的觸發，這種狀況是比較常見的；
  • 多對多同步模型：多個任務等待多個事件的觸發，任務能夠經過設置事件位來實現事件的觸發和等待操做。

事件數據結構

事件控制塊

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)0x0004複製代碼
  • TOS_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 對事件銷燬的處理流程以下：

  1. 調用pend_is_nopending()函數判斷一下是否有任務在等待事件
  2. 若是有任務在等待事件則調用pend_wakeup_all()函數將這些任務喚醒，而且告知等待任務事件已經被銷燬了（即設置任務控制塊中的等待狀態成員變量pend_state爲PEND_STATE_DESTROY）。
  3. 調用pend_object_deinit()函數將事件控制塊中的內容清除，最主要的是將控制塊中的資源類型設置爲PEND_TYPE_NONE，這樣子就沒法使用這個事件了。
  4. 將event->flag成員變量恢復爲默認值0。
  5. 進行任務調度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由用戶指定，在這段時間中，若是事件一直沒發生，該任務將保持阻塞狀態以等待事件發生。當其它任務或中斷服務程序往其等待的事件旗標設置對應的標誌位，該任務將自動由阻塞態轉爲就緒態。當任務等待的時間超過了指定的阻塞時間，即便事件還未發生，任務也會自動從阻塞態轉移爲就緒態。這樣子頗有效的體現了操做系統的實時性。

任務獲取了某個事件時，能夠選擇清除事件操做。

等待事件的操做不容許在中斷上下文環境運行！

等待事件的過程以下：

  1. 首先檢測傳入的參數是否正確。，注意opt_pend的選項必須存在TOS_OPT_EVENT_PEND_ALL 或者 TOS_OPT_EVENT_PEND_ANY 之一，且兩者不容許同時存在（互斥）。
  2. 調用event_is_match()函數判斷等待的事件是否已發生（即任務等待的事件與事件控制塊中的旗標是否匹配）。
  3. 在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)。
  4. 若是事件未發生則可能會阻塞當前獲取的任務，看一下用戶指定的阻塞時間timeout是否爲不阻塞TOS_TIME_NOWAIT，若是不阻塞則直接返回K_ERR_PEND_NOWAIT錯誤代碼。
  5. 若是調度器被鎖了knl_is_sched_locked()，則沒法進行等待操做，返回錯誤代碼K_ERR_PEND_SCHED_LOCKED，畢竟須要切換任務，調度器被鎖則沒法切換任務。
  6. 將任務控制塊中關於事件的變量設置一下，即設置任務指望等待的事件k_curr_task->flag_expect，任務匹配的事件k_curr_task->flag_match，以及任務等待事件的選項k_curr_task->opt_event_pend。
  7. 調用pend_task_block()函數將任務阻塞，該函數實際上就是將任務從就緒列表中移除k_rdyq.task_list_head[task_prio]，而且插入到等待列表中object->list，若是等待的時間不是永久等待TOS_TIME_FOREVER，還會將任務插入時間列表中k_tick_list，阻塞時間爲timeout，而後進行一次任務調度knl_sched()。
  8. 當程序能繼續往下執行時，則表示任務等待到事件，又或者等待發生了超時，任務就不須要等待事件了，此時將任務控制塊中的內容清空，即清空任務指望等待的事件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()函數中的處理也是很是簡單明瞭的，其執行思路以下：

  1. 首先判斷一下發生事件的方式opt_post，若是是OPT_EVENT_POST_KEP則採用或運算「|」寫入事件旗標，不然直接賦值。
  2. 使用TOS_LIST_FOR_EACH_SAFE遍歷等待在事件對象上的事件等待列表，經過event_is_match()函數判斷是否有任務指望的事件與當前事件旗標的值匹配，若是有則調用pend_task_wakeup()函數喚醒對應的任務。
  3. 若是喚醒的等待任務指定了清除對應的事件，那麼將清除事件的旗標值。
  4. 最後進行一次任務調度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開發」公衆號

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程