【TencentOS tiny】深度源碼分析（6）——互斥鎖

時間  2020-05-11
標籤 TencentOS tiny 深度 源碼 分析 互斥 简体版
原文   原文鏈接

互斥鎖

互斥鎖又稱互斥互斥鎖，是一種特殊的信號量，它和信號量不一樣的是，它具備互斥鎖全部權、遞歸訪問以及優先級繼承等特性，在操做系統中經常使用於對臨界資源的獨佔式處理。在任意時刻互斥鎖的狀態只有兩種，開鎖或閉鎖，當互斥鎖被任務持有時，該互斥鎖處於閉鎖狀態，當該任務釋放互斥鎖時，該互斥鎖處於開鎖狀態。算法

  • 一個任務持有互斥鎖就表示它擁有互斥鎖的全部權，只有該任務才能釋放互斥鎖，同時其餘任務將不能持有該互斥鎖，這就是互斥鎖的全部權特性。
  • 當持有互斥鎖的任務再次獲取互斥鎖時不會被掛起，而是能遞歸獲取，這就是互斥鎖的遞歸訪問特性。這個特性與通常的信號量有很大的不一樣，在信號量中，因爲已經不存在可用的信號量，任務遞歸獲取信號量時會發生掛起任務最終造成死鎖。
  • 互斥鎖還擁有優先級繼承機制，它能夠將低優先級任務的優先級臨時提高到與獲取互斥鎖的高優先級任務的優先級相同，儘量下降優先級翻轉的危害。

在實際應用中，若是想要實現同步功能，可使用信號量，雖然互斥鎖也能夠用於任務與任務間的同步，但互斥鎖更多的是用於臨界資源的互斥訪問。數據結構

使用互斥鎖對臨界資源保護時，任務必須先獲取互斥鎖以得到訪問該資源的全部權，當任務使用資源後，必須釋放互斥鎖以便其餘任務能夠訪問該資源（而使用信號量保護臨界資源時則可能發生優先級翻轉，且危害是不可控的）。函數

優先級翻轉

簡單來講就是高優先級任務在等待低優先級任務執行完畢，這已經違背了操做系統的設計初衷（搶佔式調度）。post

爲何會發生優先級翻轉？ui

當系統中某個臨界資源受到一個互斥鎖保護時，任務訪問該資源時須要得到互斥鎖，若是這個資源正在被一個低優先級任務使用，此時互斥鎖處於閉鎖狀態；若是此時一個高優先級任務想要訪問該資源，那麼高優先級任務會由於獲取不到互斥鎖而進入阻塞態，此時就造成高優先級任務在等待低優先級任務運行（等待它釋放互斥鎖）。spa

優先級翻轉是會產生危害的，在一開始設計系統的時候，就已經指定任務的優先級，越重要的任務優先級越高，可是發生優先級翻轉後，高優先級任務在等待低優先級任務，這就有可能讓高優先級任務得不到有效的處理，嚴重時可能致使系統崩潰。操作系統

優先級翻轉的危害是不可控的，由於低優先級任務極可能會被系統中其餘中間優先級任務（低優先級與高優先級任務之間的優先級任務）搶佔，這就有可能致使高優先級任務將等待全部中間優先級任務運行完畢的狀況，這種狀況對高優先級任務來講是不可接受的，也是違背了操做系統設計的原則。設計

優先級繼承

在TencentOS tiny 中爲了下降優先級翻轉產生的危害使用了優先級繼承算法：暫時提升佔有某種臨界資源的低優先級任務的優先級，使之與在全部等待該資源的任務中，優先級最高的任務優先級相等，而當這個低優先級任務執行完畢釋放該資源時，優先級恢復初始設定值（此處能夠看做是低優先級任務臨時繼承了高優先級任務的優先級）。所以，繼承優先級的任務避免了系統資源被任何中間優先級任務搶佔。互斥鎖的優先級繼承機制，它確保高優先級任務進入阻塞狀態的時間儘量短，以及將已經出現的「優先級翻轉」危害下降到最小，但不能消除優先級翻轉帶來的危害。指針

值得一提的是TencentOS tiny 在持有互斥鎖時還容許調用修改任務優先級的API接口。code

互斥鎖的數據結構

互斥鎖控制塊

TencentOS tiny 經過互斥鎖控制塊操做互斥鎖，其數據類型爲k_mutex_t，互斥鎖控制塊由多個元素組成。

  • pend_obj有點相似於面向對象的繼承，繼承一些屬性，裏面有描述內核資源的類型（如互斥鎖、隊列、互斥量等，同時還有一個等待列表list）。
  • pend_nesting其實是一個uint8_t類型的變量，記錄互斥鎖被獲取的次數，若是pend_nesting爲0則表示開鎖狀態，不爲0則表示閉鎖狀態，且它的值記錄了互斥量被獲取的次數（擁有遞歸訪問特性）
  • *owner是任務控制塊指針，記錄當前互斥鎖被哪一個任務持有。
  • owner_orig_prio變量記錄了持有互斥鎖任務的優先級，由於有可能發生優先級繼承機制而臨時改變任務的優先級。（擁有優先級繼承機制）。
  • owner_list是一個列表節點，當互斥鎖被任務獲取時，該節點會被添加到任務控制塊的task->mutex_own_list列表中，表示任務本身獲取到的互斥鎖有哪些。當互斥鎖被徹底釋放時（pend_nesting等於0），該節點將從任務控制塊的task->mutex_own_list列表中移除。
  • prio_pending變量比較有意思：在通常的操做系統中，任務在持有互斥鎖時不容許修改優先級，但在TencentOS tiny 中是容許的，就是由於這個變量，當一個任務處於互斥鎖優先級反轉的時候，我假設他由於優先級反轉優先級獲得了提高，此時有用戶企圖改變這個任務的優先級，但這個更改後的優先級會使此任務違背其優先級必須比全部等待他所持有的互斥鎖的任務還高的原則時，此時須要將用戶的此次優先級更改請求記錄到prio_pending裏，待其釋放其所持有的互斥鎖後再更改，至關於將任務優先級的更改延後了。
舉個例子：比如一個任務優先級是10，且持有一把鎖，此時一個優先級爲6的任務嘗試獲取這把鎖，那麼此任務優先級會被提高爲6，若是此時用戶試圖更改他的優先級爲7，那麼不能馬上響應此次請求，必需要等這把鎖放掉的時候才能作真正的優先級修改 
typedef struct k_mutex_st {
    pend_obj_t      pend_obj;
    k_nesting_t     pend_nesting;
    k_task_t       *owner;
    k_prio_t        owner_orig_prio;
    k_list_t        owner_list;
} k_mutex_t;
typedef struct k_task_st {
#if TOS_CFG_MUTEX_EN > 0u
    k_list_t            mutex_own_list;     /**< 任務擁有的互斥量 */
    k_prio_t            prio_pending;       /*< 在持有互斥鎖時修改任務優先級將被記錄到這個變量中，在釋放持有的互斥鎖時再更改 */
#endif
} k_task_t;

與互斥鎖相關的宏定義

在tos_config.h中，使能互斥鎖的宏定義是TOS_CFG_MUTEX_EN

#define TOS_CFG_MUTEX_EN            1u

建立互斥鎖

系統中每一個互斥鎖都有對應的互斥鎖控制塊，互斥鎖控制塊中包含了互斥鎖的全部信息，好比它的等待列表、它的資源類型，以及它的互斥鎖值，那麼能夠想象一下，建立互斥鎖的本質是否是就是對互斥鎖控制塊進行初始化呢？很顯然就是這樣子的。由於在後續對互斥鎖的操做都是經過互斥鎖控制塊來操做的，若是控制塊沒有信息，那怎麼能操做嘛~

建立互斥鎖函數是tos_mutex_create()，傳入一個互斥鎖控制塊的指針*mutex便可。

互斥鎖的建立實際上就是調用pend_object_init()函數將互斥鎖控制塊中的mutex->pend_obj成員變量進行初始化，它的資源類型被標識爲PEND_TYPE_MUTEX。而後將mutex->pend_nesting成員變量設置爲0，表示互斥鎖處於開鎖狀態；將mutex->owner成員變量設置爲K_NULL，表示此事並沒有任務持有互斥鎖；將mutex->owner_orig_prio成員變量設置爲默認值K_TASK_PRIO_INVALID，畢竟此事沒有任務持有互斥鎖，也無需記錄持有互斥鎖任務的優先級。最終調用tos_list_init()函數將互斥鎖的持有互斥鎖任務的列表節點owner_list。

__API__ k_err_t tos_mutex_create(k_mutex_t *mutex)
{
    TOS_PTR_SANITY_CHECK(mutex);

    pend_object_init(&mutex->pend_obj, PEND_TYPE_MUTEX);
    mutex->pend_nesting     = (k_nesting_t)0u;
    mutex->owner            = K_NULL;
    mutex->owner_orig_prio  = K_TASK_PRIO_INVALID;
    tos_list_init(&mutex->owner_list);

    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. 將mutex->pend_nesting成員變量恢復爲默認值0。
  5. 若是刪除的時候有任務持有互斥鎖，那麼調用mutex_old_owner_release()函數將互斥鎖釋放。
  6. 進行任務調度knl_sched()

注意：若是互斥鎖控制塊的RAM是由編譯器靜態分配的，因此即便是銷燬了互斥鎖，這個內存也是沒辦法釋放的。固然你也可使用動態內存爲互斥鎖控制塊分配內存，只不過在銷燬後要將這個內存釋放掉，避免內存泄漏。

__API__ k_err_t tos_mutex_destroy(k_mutex_t *mutex)
{
    TOS_CPU_CPSR_ALLOC();

    TOS_PTR_SANITY_CHECK(mutex);

#if TOS_CFG_OBJECT_VERIFY_EN > 0u
    if (!pend_object_verify(&mutex->pend_obj, PEND_TYPE_MUTEX)) {
        return K_ERR_OBJ_INVALID;
    }
#endif

    TOS_CPU_INT_DISABLE();

    if (!pend_is_nopending(&mutex->pend_obj)) {
        pend_wakeup_all(&mutex->pend_obj, PEND_STATE_DESTROY);
    }

    pend_object_deinit(&mutex->pend_obj);
    mutex->pend_nesting = (k_nesting_t)0u;

    if (mutex->owner) {
        mutex_old_owner_release(mutex);
    }

    TOS_CPU_INT_ENABLE();
    knl_sched();

    return K_ERR_NONE;
}

獲取互斥鎖

tos_mutex_pend_timed()函數用於獲取互斥鎖，互斥鎖就像是臨界資源的令牌，任務只有獲取到互斥鎖時才能訪問臨界資源。當且僅當互斥鎖處於開鎖的狀態，任務才能獲取互斥鎖成功，當任務持有了某個互斥鎖的時候，其它任務就沒法獲取這個互斥鎖，須要等到持有互斥鎖的任務進行釋放後，其餘任務才能獲取成功，任務經過互斥鎖獲取函數來獲取互斥鎖的全部權，任務對互斥鎖的全部權是獨佔的，任意時刻互斥鎖只能被一個任務持有，若是互斥鎖處於開鎖狀態，那麼獲取該互斥鎖的任務將成功得到該互斥鎖，並擁有互斥鎖的使用權；若是互斥鎖處於閉鎖狀態，獲取該互斥鎖的任務將沒法得到互斥鎖，任務將可能被阻塞，也可能當即返回，阻塞時間timeout由用戶指定，在指定時間還沒法獲取到互斥鎖時，將發送超時，等待任務將自動恢復爲就緒態。在任務被阻塞以前，會進行優先級繼承，若是當前任務優先級比持有互斥鎖的任務優先級高，那麼將會臨時提高持有互斥鎖任務的優先級。

TencentOS tiny 提供兩組API接口用於獲取互斥鎖，分別是tos_mutex_pend_timed()和tos_mutex_pend()，主要的差異是參數不一樣：可選阻塞與永久阻塞獲取互斥鎖，實際獲取的過程都是同樣的。獲取互斥鎖的過程以下：

  1. 首先檢測傳入的參數是否正確，此處不只會檢查互斥鎖控制塊的信息，還會調用TOS_IN_IRQ_CHECK()檢查上下文是否處於中斷中，由於互斥鎖的操做是不容許在中斷中進行的。
  2. 判斷互斥鎖控制塊中的mutex->pend_nesting成員變量是否爲0，爲0表示互斥鎖處於開鎖狀態，調用mutex_fresh_owner_mark()函數將獲取互斥鎖任務的相關信息保存到互斥鎖控制塊中，如mutex->pend_nesting成員變量的值變爲1表示互斥鎖處於閉鎖狀態，其餘任務沒法獲取，mutex->owner成員變量指向當前獲取互斥鎖的任務控制塊，mutex->owner_orig_prio成員變量則是記錄當前任務的優先級，最終使用tos_list_add()函數將互斥鎖控制塊的mutex->owner_list節點掛載到任務控制塊的task->mutex_own_list列表中，任務獲取成功後返回K_ERR_NONE。
  3. 若是互斥鎖控制塊中的mutex->pend_nesting成員變量不爲0，則表示互斥鎖處於閉鎖狀態，那麼因爲互斥鎖具備遞歸訪問特性，那麼會判斷一下是否是已經持有互斥鎖的任務再次獲取互斥鎖（knl_is_self()），由於這也是容許的，判斷一下mutex->pend_nesting 成員變量的值是否爲(k_nesting_t)-1，若是是則表示遞歸訪問次數達到最大值，互斥鎖已經溢出了，返回錯誤代碼K_ERR_MUTEX_NESTING_OVERFLOW。不然就將mutex->pend_nesting成員變量的值加1，返回K_ERR_MUTEX_NESTING表示遞歸獲取成功。
  4. 若是互斥鎖處於閉鎖狀態，且當前任務並未持有互斥鎖，看一下用戶指定的阻塞時間timeout是否爲不阻塞TOS_TIME_NOWAIT，若是不阻塞則直接返回K_ERR_PEND_NOWAIT錯誤代碼。
  5. 若是調度器被鎖了knl_is_sched_locked()，則沒法進行等待操做，返回錯誤代碼K_ERR_PEND_SCHED_LOCKED，畢竟須要切換任務，調度器被鎖則沒法切換任務。
  6. 最最最最重要的特性來了，在阻塞當前任務以前，須要判斷一下當前任務與持有互斥鎖的任務優先級大小狀況，若是當前任務優先級比持有互斥鎖任務優先級大，則須要進行優先級繼承，臨時將持有互斥鎖任務的優先級提高到當前優先級，經過tos_task_prio_change()函數進行改變優先級。
  7. 調用pend_task_block()函數將任務阻塞，該函數實際上就是將任務從就緒列表中移除k_rdyq.task_list_head[task_prio]，而且插入到等待列表中object->list，若是等待的時間不是永久等待TOS_TIME_FOREVER，還會將任務插入時間列表中k_tick_list，阻塞時間爲timeout，而後進行一次任務調度knl_sched()。
  8. 當程序能行到pend_state2errno()時，則表示任務等獲取到互斥鎖，又或者等待發生了超時，那麼就調用pend_state2errno()函數獲取一下任務的等待狀態，看一下是哪一種狀況致使任務恢復運行，若是任務已經獲取到互斥鎖，那麼須要調用mutex_new_owner_mark()函數標記一下獲取任務的信息，將獲取互斥鎖任務的相關信息保存到互斥鎖控制塊中。

注意：當獲取互斥鎖的任務能從阻塞中恢復運行，也不必定是獲取到互斥鎖，也多是發生了超時，所以在寫程序的時候必需要判斷一下獲取的互斥鎖狀態，若是返回值是K_ERR_NONE與K_ERR_MUTEX_NESTING則表示獲取成功！

__API__ k_err_t tos_mutex_pend_timed(k_mutex_t *mutex, k_tick_t timeout)
{
    TOS_CPU_CPSR_ALLOC();
    k_err_t err;

    TOS_PTR_SANITY_CHECK(mutex);
    TOS_IN_IRQ_CHECK();

#if TOS_CFG_OBJECT_VERIFY_EN > 0u
    if (!pend_object_verify(&mutex->pend_obj, PEND_TYPE_MUTEX)) {
        return K_ERR_OBJ_INVALID;
    }
#endif

    TOS_CPU_INT_DISABLE();
    if (mutex->pend_nesting == (k_nesting_t)0u) { // first come
        mutex_fresh_owner_mark(mutex, k_curr_task);
        TOS_CPU_INT_ENABLE();
        return K_ERR_NONE;
    }

    if (knl_is_self(mutex->owner)) { // come again
        if (mutex->pend_nesting == (k_nesting_t)-1) {
            TOS_CPU_INT_ENABLE();
            return K_ERR_MUTEX_NESTING_OVERFLOW;
        }
        ++mutex->pend_nesting;
        TOS_CPU_INT_ENABLE();
        return K_ERR_MUTEX_NESTING;
    }

    if (timeout == TOS_TIME_NOWAIT) { // no wait, return immediately
        TOS_CPU_INT_ENABLE();
        return K_ERR_PEND_NOWAIT;
    }

    if (knl_is_sched_locked()) {
        TOS_CPU_INT_ENABLE();
        return K_ERR_PEND_SCHED_LOCKED;
    }

    if (mutex->owner->prio > k_curr_task->prio) {
        // PRIORITY INVERSION:
        // we are declaring a mutex, which's owner has a lower(numerically bigger) priority.
        // make owner the same priority with us.
        tos_task_prio_change(mutex->owner, k_curr_task->prio);
    }

    pend_task_block(k_curr_task, &mutex->pend_obj, timeout);

    TOS_CPU_INT_ENABLE();
    knl_sched();

    err = pend_state2errno(k_curr_task->pend_state);

    if (err == K_ERR_NONE) {
        // good, we are the owner now.
        TOS_CPU_INT_DISABLE();
        mutex_new_owner_mark(mutex, k_curr_task);
        TOS_CPU_INT_ENABLE();
    }

    return err;
}

__API__ k_err_t tos_mutex_pend(k_mutex_t *mutex)
{
    TOS_PTR_SANITY_CHECK(mutex);

    return tos_mutex_pend_timed(mutex, TOS_TIME_FOREVER);
}

mutex_fresh_owner_mark與mutex_new_owner_mark()函數的實現：

__STATIC_INLINE__ void mutex_fresh_owner_mark(k_mutex_t *mutex, k_task_t *task)
{
    mutex->pend_nesting     = (k_nesting_t)1u;
    mutex->owner            = task;
    mutex->owner_orig_prio  = task->prio;

    tos_list_add(&mutex->owner_list, &task->mutex_own_list);
}

__STATIC_INLINE__ void mutex_new_owner_mark(k_mutex_t *mutex, k_task_t *task)
{
    k_prio_t highest_pending_prio;

    mutex_fresh_owner_mark(mutex, task);

    // we own the mutex now, make sure our priority is higher than any one in the pend list.
    highest_pending_prio = pend_highest_prio_get(&mutex->pend_obj);
    if (task->prio > highest_pending_prio) {
        tos_task_prio_change(task, highest_pending_prio);
    }
}

釋放互斥鎖

互斥鎖的釋放是不容許在中斷中釋放的，主要的緣由是由於中斷中沒有上下文的概念，因此中斷上下文不能持有，也不能釋放互斥鎖；互斥鎖有所屬關係，只有持有互斥鎖的任務才能將互斥鎖釋放，而持有者是任務。

任務想要訪問某個資源的時候，須要先獲取互斥鎖，而後進行資源訪問，在任務使用完該資源的時候，必需要及時釋放互斥鎖，這樣別的任務才能訪問臨界資源。任務能夠調用tos_mutex_post()函數進行釋放互斥鎖，當互斥鎖處於開鎖狀態時就表示我已經用完了，別人能夠獲取互斥鎖以訪問臨界資源。

使用tos_mutex_post()函數接口時，只有已持有互斥鎖全部權的任務才能釋放它，當任務調用tos_mutex_post()函數時會將互斥鎖釋放一次，當互斥鎖徹底釋放完畢（mutex->pend_nesting成員變量的值爲0）就變爲開鎖狀態，等待獲取該互斥鎖的任務將被喚醒。若是任務的優先級被互斥鎖的優先級翻起色制臨時提高，那麼當互斥鎖被釋放後，任務的優先級將恢復爲本來設定的優先級。

TencentOS tiny 中能夠只讓等待中的一個任務獲取到互斥鎖（在等待的任務中具備最高優先級）。

在tos_mutex_post()函數中的處理也是很是簡單明瞭的，其執行思路以下：

  1. 首先進行傳入的互斥鎖控制塊相關的參數檢測，而後判斷一下是不是持有互斥鎖的任務來釋放互斥鎖，若是是則進行釋放操做，若是不是則返回錯誤代碼K_ERR_MUTEX_NOT_OWNER。
  2. 將mutex->pend_nesting成員變量的值減1，而後判斷它的值是否爲0，若是不爲0則表示當前任務仍是持有互斥鎖的，也無需進行後續的操做，直接返回K_ERR_MUTEX_NESTING。
  3. 若是mutex->pend_nesting成員變量的值爲0，則表示互斥鎖處於開鎖狀態，則須要調用mutex_old_owner_release()函數徹底釋放掉互斥鎖，在這個函數中會將互斥鎖控制塊的成員變量（如owner_list、owner、owner_orig_prio等都設置爲初始值），此外還有最重要的就是判斷一下任務是否發生過優先級繼承，若是是則須要將任務恢復爲本來的優先級，不然就無效理會。
  4. 調用pend_is_nopending()函數判斷一下是否有任務在等待互斥鎖，若是沒有則返回K_ERR_NONE表示釋放互斥鎖成功，由於此時沒有喚醒任務也就無需任務調度，直接返回便可。
  5. 若是有任務在等待互斥鎖，則直接調用pend_wakeup_one()函數喚醒一個等待任務，這個任務在等待任務中是處於最高優先級的，由於TencentOS tiny 的等待任務是按照優先級進行排序。
  6. 進行一次任務調度knl_sched()。
__API__ k_err_t tos_mutex_post(k_mutex_t *mutex)
{
    TOS_CPU_CPSR_ALLOC();

    TOS_PTR_SANITY_CHECK(mutex);

#if TOS_CFG_OBJECT_VERIFY_EN > 0u
    if (!pend_object_verify(&mutex->pend_obj, PEND_TYPE_MUTEX)) {
        return K_ERR_OBJ_INVALID;
    }
#endif

    TOS_CPU_INT_DISABLE();
    if (!knl_is_self(mutex->owner)) {
        TOS_CPU_INT_ENABLE();
        return K_ERR_MUTEX_NOT_OWNER;
    }

    if (mutex->pend_nesting == (k_nesting_t)0u) {
        TOS_CPU_INT_ENABLE();
        return K_ERR_MUTEX_NESTING_OVERFLOW;
    }

    --mutex->pend_nesting;
    if (mutex->pend_nesting > (k_nesting_t)0u) {
        TOS_CPU_INT_ENABLE();
        return K_ERR_MUTEX_NESTING;
    }

    mutex_old_owner_release(mutex);

    if (pend_is_nopending(&mutex->pend_obj)) {
        TOS_CPU_INT_ENABLE();
        return K_ERR_NONE;
    }

    pend_wakeup_one(&mutex->pend_obj, PEND_STATE_POST);
    TOS_CPU_INT_ENABLE();
    knl_sched();

    return K_ERR_NONE;
}

持有互斥鎖的任務釋放互斥鎖mutex_old_owner_release()。

__STATIC_INLINE__ void mutex_old_owner_release(k_mutex_t *mutex)
{
    k_task_t *owner;

    owner = mutex->owner;

    tos_list_del(&mutex->owner_list);
    mutex->owner = K_NULL;

    // the right time comes! let's do it!
    if (owner->prio_pending != K_TASK_PRIO_INVALID) {
        tos_task_prio_change(owner, owner->prio_pending);
        owner->prio_pending = K_TASK_PRIO_INVALID;
    } else if (owner->prio != mutex->owner_orig_prio) {
        tos_task_prio_change(owner, mutex->owner_orig_prio);
        mutex->owner_orig_prio = K_TASK_PRIO_INVALID;
    }
}

喜歡就關注我吧！

歡迎關注我公衆號

相關代碼能夠在公衆號後臺回覆 「 19 」 獲取。歡迎關注「物聯網IoT開發」公衆號

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