【原創】Linux Mutex機制分析

背景

• Read the fucking source code! --By 魯迅
• A picture is worth a thousand words. --By 高爾基

說明：

1. Kernel版本：4.14
2. ARM64處理器，Contex-A53，雙核
3. 使用工具：Source Insight 3.5， Visio

1. 概述

• Mutex互斥鎖是Linux內核中用於互斥操做的一種同步原語；
• 互斥鎖是一種休眠鎖，鎖爭用時可能存在進程的睡眠與喚醒，context的切換帶來的代價較高，適用於加鎖時間較長的場景；
• 互斥鎖每次只容許一個進程進入臨界區，有點相似於二值信號量；
• 互斥鎖在鎖爭用時，在鎖被持有時，選擇自選等待，而不當即進行休眠，能夠極大的提升性能，這種機制（optimistic spinning）也應用到了讀寫信號量上；
• 互斥鎖的缺點是互斥鎖對象的結構較大，會佔用更多的CPU緩存和內存空間；
• 與信號量相比，互斥鎖的性能與擴展性都更好，所以，在內核中老是會優先考慮互斥鎖；
• 互斥鎖按爲了提升性能，提供了三條路徑處理：快速路徑，中速路徑，慢速路徑；

前戲都已經講完了，來看看實際的實現過程吧。

2. optimistic spinning

2.1 MCS鎖

• 上文中提到過Mutex在實現過程當中，採用了optimistic spinning自旋等待機制，這個機制的核心就是基於MCS鎖機制來實現的；
• MCS鎖機制是由John Mellor Crummey和Michael Scott在論文中《algorithms for scalable synchronization on shared-memory multiprocessors》提出的，並以他倆的名字來命名；
• MCS鎖機制要解決的問題是：在多CPU系統中，自旋鎖都在同一個變量上進行自旋，在獲取鎖時會將包含鎖的cache line移動到本地CPU，這種cache-line bouncing會很大程度影響性能；
• MCS鎖機制的核心思想：每一個CPU都分配一個自旋鎖結構體，自旋鎖的申請者（per-CPU）在local-CPU變量上自旋，這些結構體組建成一個鏈表，申請者自旋等待前驅節點釋放該鎖；
• osq(optimistci spinning queue)是基於MCS算法的一個具體實現，並通過了迭代優化；

2.2 osq流程分析

optimistic spinning，樂觀自旋，到底有多樂觀呢？當發現鎖被持有時，optimistic spinning相信持有者很快就能把鎖釋放，所以它選擇自旋等待，而不是睡眠等待，這樣也就能減小進程切換帶來的開銷了。

看一下數據結構吧：

osq_lock以下：

• osq加鎖有幾種狀況：
  1. 無人持有鎖，那是最理想的狀態，直接返回；
  2. 有人持有鎖，將當前的Node加入到OSQ隊列中，在沒有高優先級任務搶佔時，自旋等待前驅節點釋放鎖；
  3. 自旋等待過程當中，若是遇到高優先級任務搶佔，那麼須要作的事情就是將以前加入到OSQ隊列中的當前節點，從OSQ隊列中移除，移除的過程又分爲三個步驟，分別是處理prev前驅節點的next指針指向、當前節點Node的next指針指向、以及將prev節點與next後繼節點鏈接；
• 加鎖過程當中使用了原子操做，來確保正確性；

osq_unlock以下：

• 解鎖時也分爲幾種狀況：
  1. 無人爭用該鎖，那直接能夠釋放鎖；
  2. 獲取當前節點指向的下一個節點，若是下一個節點不爲NULL，則將下一個節點解鎖；
  3. 當前節點的下一個節點爲NULL，則調用osq_wait_next，來等待獲取下一個節點，並在獲取成功後對下一個節點進行解鎖；
• 從解鎖的狀況能夠看出，這個過程至關於鎖的傳遞，從上一個節點傳遞給下一個節點；

在加鎖和解鎖的過程當中，因爲可能存在操做來更改osq隊列，所以都調用了osq_wait_next來獲取下一個肯定的節點：

3. mutex

3.1 數據結構

終於來到了主題了，先看一下數據結構：

struct mutex {
	atomic_long_t		owner;           //原子計數，用於指向鎖持有者的task struct結構
	spinlock_t		wait_lock;              //自旋鎖，用於wait_list鏈表的保護操做
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
	struct optimistic_spin_queue osq; /* Spinner MCS lock */        //osq鎖
#endif
	struct list_head	wait_list;          //鏈表，用於管理全部在該互斥鎖上睡眠的進程
#ifdef CONFIG_DEBUG_MUTEXES
	void			*magic;
#endif
#ifdef CONFIG_DEBUG_LOCK_ALLOC
	struct lockdep_map	dep_map;
#endif
};

在使用mutex時，有如下幾點須要注意的：

• 一次只能有一個進程能持有互斥鎖；
• 只有鎖的持有者能進行解鎖操做；
• 禁止屢次解鎖操做；
• 禁止遞歸加鎖操做；
• mutex結構只能經過API進行初始化；
• mutex結構禁止經過memset或者拷貝來進行初始化；
• 已經被持有的mutex鎖禁止被再次初始化；
• mutex不容許在硬件或軟件上下文（tasklets, timer）中使用；

3.2 加鎖流程分析

從mutex_lock加鎖來看一下大概的流程：

• mutex_lock爲了提升性能，分爲三種路徑處理，優先使用快速和中速路徑來處理，若是條件不知足則會跳轉到慢速路徑來處理，慢速路徑中會進行睡眠和調度，所以開銷也是最大的。

3.2.1 fast-path

• 快速路徑是在__mutex_trylock_fast中實現的，該函數的實現也很簡單，直接調用atomic_long_cmpxchg_release(&lock->owner, 0UL, curr)函數來進行判斷，若是lock->owner == 0代表鎖未被持有，將curr賦值給lock->owner標識curr進程持有該鎖，並直接返回；
• lock->owner不等於0，代表鎖被持有，須要進入下一個路徑來處理了；

3.2.2 mid-path

• 中速路徑和慢速路徑的處理都是在__mutex_lock_common中實現的；
• __mutex_lock_common的傳入參數爲(lock, TASK_INTERRUPTIBLE, 0, NULL, _RET_IP_, false)，該函數中不少路徑覆蓋不到，接下來的分析也會剔除掉無效代碼；

中速路徑的核心代碼以下：

• 當發現mutex鎖的持有者正在運行（另外一個CPU）時，能夠不進行睡眠調度，而能夠選擇自選等待，當鎖持有者正在運行時，它頗有可能很快會釋放鎖，這個就是樂觀自旋的緣由；

• 自旋等待的條件是持有鎖者正在臨界區運行，自旋等待纔有價值；

• __mutex_trylock_or_owner函數用於嘗試獲取鎖，若是獲取失敗則返回鎖的持有者。互斥鎖的結構體中owner字段，分爲兩個部分：1）鎖持有者進程的task_struct（因爲L1_CACHE_BYTES對齊，低位比特沒有使用）；2）MUTEX_FLAGS部分，也就是對應低三位，以下：

  1. MUTEX_FLAG_WAITERS：比特0，標識存在非空等待者鏈表，在解鎖的時候須要執行喚醒操做；
  2. MUTEX_FLAG_HANDOFF：比特1，代表解鎖的時候須要將鎖傳遞給頂部的等待者；
  3. MUTEX_FLAG_PICKUP：比特2，代表鎖的交接準備已經作完了，能夠等待被取走了；

• mutex_optimistic_spin用於執行樂觀自旋，理想的狀況下鎖持有者執行完釋放，當前進程就能很快的獲取到鎖。實際須要考慮，若是鎖的持有者若是在臨界區被調度出去了，task_struct->on_cpu == 0，那麼須要結束自旋等待了，不然豈不是傻傻等待了。

  1. mutex_can_spin_on_owner：進入自旋前檢查一下，若是當前進程須要調度，或者鎖的持有者已經被調度出去了，那麼直接就返回了，不須要作接下來的osq_lock/oqs_unlock工做了，節省一些額外的overhead；
  2. osq_lock用於確保只有一個等待者參與進來自旋，防止大量的等待者蜂擁而至來獲取互斥鎖；
  3. for(;;)自旋過程當中調用__mutex_trylock_or_owner來嘗試獲取鎖，獲取到後皆大歡喜，直接返回便可；
  4. mutex_spin_on_owner，判斷不知足自旋等待的條件，那麼返回，讓咱們進入慢速路徑吧，畢竟不能強求；

3.2.3 slow-path

慢速路徑的主要代碼流程以下：

• 從for(;;)部分的流程能夠看到，當沒有獲取到鎖時，會調用schedule_preempt_disabled將自己的任務進行切換出去，睡眠等待，這也是它慢的緣由了；

3.3 釋放鎖流程分析

• 釋放鎖的流程相對來講比較簡單，也分爲快速路徑與慢速路徑，快速路徑只有在調試的時候打開；
• 慢速路徑釋放鎖，針對三種不一樣的MUTEX_FLAG來進行判斷處理，並最終喚醒等待在該鎖上的任務；

參考

Generic Mutex Subsystem
MCS locks and qspinlocks

歡迎關注我的公衆號，持續分享內核相關文章