這篇文章主要介紹“TencentOS tiny互斥鎖的原理以及實例用法”，在日常操作中，相信很多人在TencentOS tiny互斥鎖的原理以及實例用法問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”TencentOS tiny互斥鎖的原理以及實例用法”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
互斥鎖又稱互斥互斥鎖，是一種特殊的信號量，它和信號量不同的是，它具有互斥鎖所有權、遞歸訪問以及優先級繼承等特性，在操作系統中常用于對臨界資源的獨占式處理。在任意時刻互斥鎖的狀態只有兩種，開鎖或閉鎖，當互斥鎖被任務持有時，該互斥鎖處于閉鎖狀態，當該任務釋放互斥鎖時，該互斥鎖處于開鎖狀態。
一個任務持有互斥鎖就表示它擁有互斥鎖的所有權，只有該任務才能釋放互斥鎖，同時其他任務將不能持有該互斥鎖，這就是互斥鎖的所有權特性。
當持有互斥鎖的任務再次獲取互斥鎖時不會被掛起，而是能遞歸獲取，這就是互斥鎖的遞歸訪問特性。這個特性與一般的信號量有很大的不同，在信號量中，由于已經不存在可用的信號量，任務遞歸獲取信號量時會發生掛起任務最終形成死鎖。
互斥鎖還擁有優先級繼承機制，它可以將低優先級任務的優先級臨時提升到與獲取互斥鎖的高優先級任務的優先級相同，盡可能降低優先級翻轉的危害。
在實際應用中，如果想要實現同步功能，可以使用信號量，雖然互斥鎖也可以用于任務與任務間的同步，但互斥鎖更多的是用于臨界資源的互斥訪問。
使用互斥鎖對臨界資源保護時，任務必須先獲取互斥鎖以獲得訪問該資源的所有權，當任務使用資源后，必須釋放互斥鎖以便其他任務可以訪問該資源（而使用信號量保護臨界資源時則可能發生優先級翻轉，且危害是不可控的）。
簡單來說就是高優先級任務在等待低優先級任務執行完畢，這已經違背了操作系統的設計初衷（搶占式調度）。
為什么會發生優先級翻轉？
當系統中某個臨界資源受到一個互斥鎖保護時，任務訪問該資源時需要獲得互斥鎖，如果這個資源正在被一個低優先級任務使用，此時互斥鎖處于閉鎖狀態；如果此時一個高優先級任務想要訪問該資源，那么高優先級任務會因為獲取不到互斥鎖而進入阻塞態，此時就形成高優先級任務在等待低優先級任務運行（等待它釋放互斥鎖）。
優先級翻轉是會產生危害的，在一開始設計系統的時候，就已經指定任務的優先級，越重要的任務優先級越高，但是發生優先級翻轉后，高優先級任務在等待低優先級任務，這就有可能讓高優先級任務得不到有效的處理，嚴重時可能導致系統崩潰。
優先級翻轉的危害是不可控的，因為低優先級任務很可能會被系統中其他中間優先級任務（低優先級與高優先級任務之間的優先級任務）搶占，這就有可能導致高優先級任務將等待所有中間優先級任務運行完畢的情況，這種情況對高優先級任務來說是不可接受的，也是違背了操作系統設計的原則。
在TencentOS tiny 中為了降低優先級翻轉產生的危害使用了優先級繼承算法：暫時提高占有某種臨界資源的低優先級任務的優先級，使之與在所有等待該資源的任務中，優先級最高的任務優先級相等，而當這個低優先級任務執行完畢釋放該資源時，優先級恢復初始設定值（此處可以看作是低優先級任務臨時繼承了高優先級任務的優先級）。因此，繼承優先級的任務避免了系統資源被任何中間優先級任務搶占?；コ怄i的優先級繼承機制，它確保高優先級任務進入阻塞狀態的時間盡可能短，以及將已經出現的“優先級翻轉”危害降低到最小，但不能消除優先級翻轉帶來的危害。
值得一提的是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;
}
}到此，關于“TencentOS tiny互斥鎖的原理以及實例用法”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
