互斥鎖互斥鎖又稱互斥互斥鎖，是一種特殊的信號量，它和信號量不同的是，它具有等特性，在操作系統中常用於對臨界資源的處理。在任意時刻互斥鎖的狀態只有兩種，，當互斥鎖被任務持有時，該互斥鎖處於閉鎖狀態，當該任務釋放互斥鎖時，該互斥鎖處於開鎖狀態。一個任務持有互斥鎖就表示它擁有互斥鎖的所有權，只有 ...

互斥鎖

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

一個任務持有互斥鎖就表示它擁有互斥鎖的所有權，只有該任務才能釋放互斥鎖，同時其他任務將不能持有該互斥鎖，這就是互斥鎖的所有權特性。
當持有互斥鎖的任務再次獲取互斥鎖時不會被掛起，而是能遞歸獲取，這就是互斥鎖的遞歸訪問特性。這個特性與一般的信號量有很大的不同，在信號量中，由於已經不存在可用的信號量，任務遞歸獲取信號量時會發生掛起任務最終形成死鎖。
互斥鎖還擁有優先順序繼承機制，它可以將低優先順序任務的優先順序臨時提升到與獲取互斥鎖的高優先順序任務的優先順序相同，儘可能降低優先順序翻轉的危害。

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

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

優先順序翻轉

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

為什麼會發生優先順序翻轉？

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

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

優先順序翻轉的危害是不可控的，因為低優先順序任務很可能會被系統中其他中間優先順序任務（低優先順序與高優先順序任務之間的優先順序任務）搶占，這就有可能導致高優先順序任務將等待所有中間優先順序任務運行完畢的情況，這種情況對高優先順序任務來說是不可接受的，也是違背了操作系統設計的原則。

優先順序繼承

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

值得一提的是TencentOS tiny 在持有互斥鎖時還允許調用修改任務優先順序的API介面。

互斥鎖的數據結構

互斥鎖控制塊

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 對互斥鎖銷毀的處理流程如下：

調用pend_is_nopending()函數判斷一下是否有任務在等待互斥鎖
如果有則調用pend_wakeup_all()函數將這些任務喚醒，並且告知等待任務互斥鎖已經被銷毀了（即設置任務控制塊中的等待狀態成員變數pend_state為PEND_STATE_DESTROY）。
調用pend_object_deinit()函數將互斥鎖控制塊中的內容清除，最主要的是將控制塊中的資源類型設置為PEND_TYPE_NONE，這樣子就無法使用這個互斥鎖了。
將mutex->pend_nesting成員變數恢復為預設值0。
如果刪除的時候有任務持有互斥鎖，那麼調用mutex_old_owner_release()函數將互斥鎖釋放。
進行任務調度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()，主要的差別是參數不同：可選阻塞與永久阻塞獲取互斥鎖，實際獲取的過程都是一樣的。獲取互斥鎖的過程如下：

首先檢測傳入的參數是否正確，此處不僅會檢查互斥鎖控制塊的信息，還會調用TOS_IN_IRQ_CHECK()檢查上下文是否處於中斷中，因為互斥鎖的操作是不允許在中斷中進行的。
判斷互斥鎖控制塊中的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。
如果互斥鎖控制塊中的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表示遞歸獲取成功。
如果互斥鎖處於閉鎖狀態，且當前任務並未持有互斥鎖，看一下用戶指定的阻塞時間timeout是否為不阻塞TOS_TIME_NOWAIT，如果不阻塞則直接返回K_ERR_PEND_NOWAIT錯誤代碼。
如果調度器被鎖了knl_is_sched_locked()，則無法進行等待操作，返回錯誤代碼K_ERR_PEND_SCHED_LOCKED，畢竟需要切換任務，調度器被鎖則無法切換任務。
最最最最重要的特性來了，在阻塞當前任務之前，需要判斷一下當前任務與持有互斥鎖的任務優先順序大小情況，如果當前任務優先順序比持有互斥鎖任務優先順序大，則需要進行優先順序繼承，臨時將持有互斥鎖任務的優先順序提升到當前優先順序，通過tos_task_prio_change()函數進行改變優先順序。
調用pend_task_block()函數將任務阻塞，該函數實際上就是將任務從就緒列表中移除k_rdyq.task_list_head[task_prio]，並且插入到等待列表中object->list，如果等待的時間不是永久等待TOS_TIME_FOREVER，還會將任務插入時間列表中k_tick_list，阻塞時間為timeout，然後進行一次任務調度knl_sched()。
當程式能行到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()函數中的處理也是非常簡單明瞭的，其執行思路如下：

首先進行傳入的互斥鎖控制塊相關的參數檢測，然後判斷一下是否是持有互斥鎖的任務來釋放互斥鎖，如果是則進行釋放操作，如果不是則返回錯誤代碼K_ERR_MUTEX_NOT_OWNER。
將mutex->pend_nesting成員變數的值減1，然後判斷它的值是否為0，如果不為0則表示當前任務還是持有互斥鎖的，也無需進行後續的操作，直接返回K_ERR_MUTEX_NESTING。
如果mutex->pend_nesting成員變數的值為0，則表示互斥鎖處於開鎖狀態，則需要調用mutex_old_owner_release()函數完全釋放掉互斥鎖，在這個函數中會將互斥鎖控制塊的成員變數（如owner_list、owner、owner_orig_prio等都設置為初始值），此外還有最重要的就是判斷一下任務是否發生過優先順序繼承，如果是則需要將任務恢復為原本的優先順序，否則就無效理會。
調用pend_is_nopending()函數判斷一下是否有任務在等待互斥鎖，如果沒有則返回K_ERR_NONE表示釋放互斥鎖成功，因為此時沒有喚醒任務也就無需任務調度，直接返回即可。
如果有任務在等待互斥鎖，則直接調用pend_wakeup_one()函數喚醒一個等待任務，這個任務在等待任務中是處於最高優先順序的，因為TencentOS tiny 的等待任務是按照優先順序進行排序。
進行一次任務調度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開發”公眾號！

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

互斥鎖