Rwsem的count成員還有一些bit用來標記當前讀寫鎖狀態（waiter bit和handoff bit），也需要根據情況進行調整：

A、如果等待隊列為空了，肯定是要清除waiter flag，同時要清除handoff flag，畢竟沒有什么等待任務可以遞交鎖了。

B、雖然隊列非空，但已經喚醒了reader，那么需要清除handoff標記，畢竟top waiter已經被喚醒去持鎖了，完成了鎖的遞交。

C、完成sem->count的調整

第二輪將喚醒的reader加入喚醒隊列，具體的邏輯如下：

主要是把等待任務對象的task成員設置為NULL，喚醒之后根據這個成員來判斷是正常喚醒還是異常喚醒路徑。

這里對喚醒等待隊列上的reader和writer處理是不一樣的。對于writer，喚醒之然后被調度到之后再去試圖持鎖。對于reader，在喚醒路徑上就已經持鎖（增加rwsem的reader count，并且修改了相關的狀態標記）。之所以這么做主要是降低調度的開銷，畢竟若干個reader線程被喚醒之后，獲得CPU資源再去持鎖，持鎖失敗然后繼續阻塞，這些都會增加調度的負載。

七、嘗試獲取寫鎖

和down_write不一樣，down_write_trylock只是嘗試獲取寫鎖，如果成功，那么自然是好的，直接返回1，如果失敗，也不會阻塞，只是返回0就可以了。代碼主邏輯在rwsem_write_trylock函數中，如下：

tmp的初始值設定為RWSEM_UNLOCKED_VALUE（0值），對于writer而言，只有rwsem是空鎖的時候才能進入臨界區。如果當前的sem->count等于0，那么給sem->count賦值RWSEM_WRITER_LOCKED，標記持鎖成功，并且把owner設定為當前task。

atomic_long_try_cmpxchg_acquire函數有三個參數，從左到右分別是value，old和new。該函數會對比value和old，如果相等那么執行賦值value=new同時返回true。如果不相等，不執行賦值操作，直接返回false。

八、獲取寫鎖

Writer獲取寫鎖的代碼主要在__down_write_common函數中，如下：

rwsem_write_trylock（快速路徑）上一節已經描述，我們主要看慢速路徑的邏輯（樂觀自旋我們下面會講，這里暫且略過）：

首先準備好一個等待任務對象（棧上）并初始化，將其掛入等待隊列。在真正睡眠之前，我們需要做一些喚醒動作（和reader持鎖過程類似，有可能在掛入等待隊列的時候，臨界區線程恰好離開，變成空鎖），具體邏輯如下：

A、如果我們是等待隊列的top waiter（等待隊列從空變為非空），那么需要設定RWSEM_FLAG_WAITERS標記，直接進入后續阻塞邏輯。如果不是，那么邏輯要復雜點，需要掃描一下之前掛入隊列的任務，看看是否需要喚醒。

B、如果是writer持鎖，那么不需要任何喚醒動作，畢竟writer是排他的

C、如果是空鎖狀態，我們需要喚醒top waiter（RWSEM_WAKE_ANY，top writer或者reader們）。你可能會疑問：為何空鎖還要喚醒等待隊列的線程？當前線程快馬加鞭去持鎖不就OK了嗎？這主要是和handoff邏輯相關，這時候更應該持鎖的是等待隊列中設置了handoff的那個waiter，而不是當前writer。如果是reader在臨界區內，那么，我們將喚醒本等待隊列頭部的所有reader（RWSEM_WAKE_READERS）。

D、上面僅僅是標記喚醒者，這里的代碼段完成具體的喚醒動作

下面進入具體writer的阻塞過程：

A、調用rwsem_try_write_lock試圖持鎖，如果成功持鎖則退出循環，不再阻塞。有兩個邏輯路徑會路過這里。一個是線程持鎖失敗進入這里，另外一個是阻塞后被喚醒試圖持鎖。

B、有pending的信號，異常路徑退出

C、持鎖失敗但是設置了handoff，那么該線程對owner進行自旋等待，以便加快鎖的傳遞。

D、進入阻塞狀態

E、喚醒之后，重新試圖持鎖。Writer和reader不一樣，writer是喚醒之后自己再通過rwsem_try_write_lock試圖持鎖，而reader是在喚醒路徑上持鎖。

rwsem_try_write_lock代碼如下：

A、如果已經設置了handoff，并且自己不是top waiter（top waiter才是鎖要遞交的對象），返回false，持鎖失敗。如果是top waiter，那么就設置handoff_set，標記自己就是鎖遞交的目標任務。

B、如果當前rwsem已經有了owner，那么說明該鎖被偷走了。在適當的條件下（等待超時）設置handoff標記，防止后續繼續被搶。如果已經設置了handoff就不必重復設置了。

C、如果當前rwsem沒有owner，則持鎖成功，清除handoff標記并根據情況設置waiter標記。

D、通過原子操作來持鎖，成功操作后退出循環，否則是有其他線程插入，需要重復上面的邏輯。

至此我們要不獲取了鎖并清除了handoff bit（B邏輯塊），或者沒有獲取鎖，僅僅是設置了handoff bit（A邏輯塊）。

九、釋放寫鎖

除了清除了owner task成員，其他邏輯和釋放讀鎖類似，不再贅述。

十、樂觀自旋的條件

只有writer在進入慢速路徑的時候才會進行樂觀自旋，而rwsem_can_spin_on_owner函數用來判斷writer是否可以樂觀自旋：

A、本cpu上需要reschedule，還自旋個毛線，趕緊去睡眠也順便觸發一次調度

B、讀取sem->owner，標記部分保存在flags臨時變量中，任務指針保存在owner中

C、如果該rwsem已經禁止了對應的nonspinnable標志，那么肯定是不能樂觀自旋了。如果當前rwsem沒有禁止，那么需要看看owner的狀態。這里需要特別說明的是：為了方便debug，我們在釋放讀鎖的時候并不會清除owner task。也就是說，對于reader而言，owner中的task信息是最后進入臨界區的那個reader，僅此而已，實際這個task可能已經離開臨界區，甚至已經銷毀都有可能。所以，如果rwsem是reader擁有，那么其實判斷owner是否在cpu上運行是沒有意義的，因此owner是reader的話是允許進行樂觀自旋的（ret的缺省值是true），通過超時來控制自旋的退出。如果rwsem是writer擁有，那么owner的的確確是正在持鎖的線程，如果該線程沒有在CPU上運行（不能很快離開臨界區），那么也不能樂觀自旋。

十一、rwsem_spin_on_owner

函數rwsem_spin_on_owner的功能是對rwsem的owner task進行樂觀自旋（即不斷輪詢其狀態，僅writer有效），詳細的代碼邏輯如下：

A、在自旋之前，首先要獲得初始的狀態（owner task指針以及2-bit LSB flag），當這些狀態發生變化才好退出自旋。

B、rwsem_owner_state函數會根據當前的owner task和flag判斷當前的owner state。owner state的狀態總結如下：

只有明確的知道當前rwsem的owner是某個writer線程且沒有禁止自旋的時候才開啟下面的自旋過程。對于其他情況，例如reader owned的場景，我們不需要spin on owner，直接返回。

C、只要owner task或者flag其一發生變化，這里就會停止輪詢，同時也會返回當前的狀態，說明停止自旋的原因。例如當owner task（一定是writer）離開臨界區的時候會清空rwsem的owner域（owner task和flag會清零），這時候自旋的writer會停止自旋，到外層函數會去試圖持鎖。當然也有可能是其他自旋writer搶到了鎖，owner task從A切到B。無論那種情況，統一終止對owner的自旋。

D、如果當前cpu需要reschedule或者owner task沒有正在運行，那么也需要停止自旋

十二、Writer的樂觀自旋

和mutex的樂觀自旋的概念是類似的，想要進行rwsem的樂觀自旋，首先要獲取osq鎖，只有獲得了osq lock才能進入rwsem的樂觀自旋，否則自旋在per cpu的mcs lock上。Writer通過rwsem_optimistic_spin完成整個樂觀自旋的過程。對于writer owned場景，自旋發生在rwsem_spin_on_owner中，上一節已經描述了，這里我們主要看reader owned的情況，這時候通過for loop不斷自旋去持鎖：

A、對于rwsem，只有writer-owned場景能清楚的知道owner task是哪一個。因此，如果是writer-owned場景，會在rwsem_spin_on_owner函數進行自旋。對于非writer-owned場景（reader-owned場景或者禁止了樂觀自旋），在rwsem_spin_on_owner函數中會直接返回。從rwsem_spin_on_owner函數返回會給出owner state，如果需要退出樂觀自旋，那么這里break掉，自旋失敗，下面就準備掛入等待隊列了。

B、每次退出rwsem_spin_on_owner并且沒有要退出自旋的時候，都試著去獲取rwsem，如果持鎖成功那么退出樂觀自旋。

C、C和D是對reader-owned場景的處理。每次rwsem的owner state發生變化（從non-reader變成reader-owned狀態）時都會重新初始化 rspin_threshold。

D、Owner state沒有發生變化，那么當前試圖持鎖的writer可以進行樂觀自旋，但是需要有一個度，畢竟rwsem的臨界區內可能有多個reader線程，這有可能使得writer樂觀自旋很長時間。設置自旋門限閾值的公式是Spinning threshold = (10 + nr_readers/2)us，最大25us（30 reader）。一旦自旋超期，那么將調用rwsem_set_nonspinnable禁止樂觀自旋。

E、對于writer-owned場景，need_resched在函數rwsem_spin_on_owner中完成，對于reader-owned場景，也是需要檢查owner task所在cpu的resched情況。畢竟當前任務如果有調度需求，無論reader持鎖還是writer持鎖場景都要停止自旋。

F、在reader-owned場景中，由于無法判定臨界區reader們的執行狀態，因此rt線程的樂觀自旋需要更加的謹慎，畢竟有可能自旋的rt線程和臨界區的reader在一個CPU上從而導致活鎖現象。當然也不能禁止rt線程的自旋，畢竟在臨界區為空的情況下，rt自旋會有一定的收益的。允許rt線程自旋的場景有兩個：

a) lock owner正在釋放鎖，sem->owner被清除但是鎖還沒有釋放。

b) 鎖是空閑的并且sem->owner已清除，但是在我們嘗試獲取鎖之前另一個任務剛剛進入并獲取了鎖（例如一個自旋的writer先于我們進入臨界區）。

十三、關于handoff

1、設置handoff標記

設置handoff往往是發生在喚醒持鎖階段。對于等待隊列的writer，喚醒之后要調度執行后才去持鎖，這是一個長路徑，很可能被其他的write或者reader把鎖搶走。喚醒等待隊列中的reader們有點不一樣，在喚醒路徑上就會從這一組待喚醒的reader們選出一個代表（一般是top waiter）去持鎖，然后再一個個的喚醒。在這個reader代表線程持鎖的時候也有可能由于writer偷鎖而失敗（reader雖然也會偷鎖，但是偷鎖的reader也會喚醒等待隊列的reader們，完成top waiter未完成的工作）。

無論是reader還是writer，如果喚醒后持鎖失敗，并且等待時間已經超過了RWSEM_WAIT_TIMEOUT，這時候就會設置handoff bit，防止等待隊列的waiter餓死。具體設置handoff bit的場景如下：

2、清除handoff標記

標記了hand off之后，快速路徑、樂觀偷鎖（reader）、樂觀自旋（writer）都無法完成持鎖，鎖最終會遞交給top waiter的線程，完成持鎖。一旦完成持鎖，handoff標記就會被清除。具體清除handoff bit的場景包括：

3、確保鎖的所有權遞交給top waiter

十四、結論

標準linux內核的讀寫鎖是在公平性、吞吐量和延遲選擇了比較均衡的策略，這樣的策略在手機平臺上（特別是重載場景下）不能算是“優秀”，只能是合格吧。實際上，在手機用戶交互場景中，我們更期望是確保用戶體驗相關線程的持鎖時延，同時兼顧吞吐量。在這樣的背景下，OPPO內核團隊對linux中的讀寫鎖進行了優化，下一次有機會可以分享我們在讀寫鎖的持鎖時延方面做的改進。