Rwsem的count成員還有一些bit用來標(biāo)記當(dāng)前讀寫鎖狀態(tài)（waiter bit和handoff bit），也需要根據(jù)情況進(jìn)行調(diào)整：

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

B、雖然隊(duì)列非空，但已經(jīng)喚醒了reader，那么需要清除handoff標(biāo)記，畢竟top waiter已經(jīng)被喚醒去持鎖了，完成了鎖的遞交。

C、完成sem->count的調(diào)整

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

主要是把等待任務(wù)對(duì)象的task成員設(shè)置為NULL，喚醒之后根據(jù)這個(gè)成員來判斷是正常喚醒還是異常喚醒路徑。

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

七、嘗試獲取寫鎖

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

tmp的初始值設(shè)定為RWSEM_UNLOCKED_VALUE（0值），對(duì)于writer而言，只有rwsem是空鎖的時(shí)候才能進(jìn)入臨界區(qū)。如果當(dāng)前的sem->count等于0，那么給sem->count賦值RWSEM_WRITER_LOCKED，標(biāo)記持鎖成功，并且把owner設(shè)定為當(dāng)前task。

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

八、獲取寫鎖

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

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

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

A、如果我們是等待隊(duì)列的top waiter（等待隊(duì)列從空變?yōu)榉强眨敲葱枰O(shè)定RWSEM_FLAG_WAITERS標(biāo)記，直接進(jìn)入后續(xù)阻塞邏輯。如果不是，那么邏輯要復(fù)雜點(diǎn)，需要掃描一下之前掛入隊(duì)列的任務(wù)，看看是否需要喚醒。

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

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

D、上面僅僅是標(biāo)記喚醒者，這里的代碼段完成具體的喚醒動(dòng)作

下面進(jìn)入具體writer的阻塞過程：

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

B、有pending的信號(hào)，異常路徑退出

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

D、進(jìn)入阻塞狀態(tài)

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

rwsem_try_write_lock代碼如下：

A、如果已經(jīng)設(shè)置了handoff，并且自己不是top waiter（top waiter才是鎖要遞交的對(duì)象），返回false，持鎖失敗。如果是top waiter，那么就設(shè)置handoff_set，標(biāo)記自己就是鎖遞交的目標(biāo)任務(wù)。

B、如果當(dāng)前rwsem已經(jīng)有了owner，那么說明該鎖被偷走了。在適當(dāng)?shù)臈l件下（等待超時(shí)）設(shè)置handoff標(biāo)記，防止后續(xù)繼續(xù)被搶。如果已經(jīng)設(shè)置了handoff就不必重復(fù)設(shè)置了。

C、如果當(dāng)前rwsem沒有owner，則持鎖成功，清除handoff標(biāo)記并根據(jù)情況設(shè)置waiter標(biāo)記。

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

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

九、釋放寫鎖

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

十、樂觀自旋的條件

只有writer在進(jìn)入慢速路徑的時(shí)候才會(huì)進(jìn)行樂觀自旋，而rwsem_can_spin_on_owner函數(shù)用來判斷writer是否可以樂觀自旋：

A、本cpu上需要reschedule，還自旋個(gè)毛線，趕緊去睡眠也順便觸發(fā)一次調(diào)度

B、讀取sem->owner，標(biāo)記部分保存在flags臨時(shí)變量中，任務(wù)指針保存在owner中

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

十一、rwsem_spin_on_owner

函數(shù)rwsem_spin_on_owner的功能是對(duì)rwsem的owner task進(jìn)行樂觀自旋（即不斷輪詢其狀態(tài)，僅writer有效），詳細(xì)的代碼邏輯如下：

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

B、rwsem_owner_state函數(shù)會(huì)根據(jù)當(dāng)前的owner task和flag判斷當(dāng)前的owner state。owner state的狀態(tài)總結(jié)如下：

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

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

D、如果當(dāng)前cpu需要reschedule或者owner task沒有正在運(yùn)行，那么也需要停止自旋

十二、Writer的樂觀自旋

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

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

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

C、C和D是對(duì)reader-owned場(chǎng)景的處理。每次rwsem的owner state發(fā)生變化（從non-reader變成reader-owned狀態(tài)）時(shí)都會(huì)重新初始化 rspin_threshold。

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

E、對(duì)于writer-owned場(chǎng)景，need_resched在函數(shù)rwsem_spin_on_owner中完成，對(duì)于reader-owned場(chǎng)景，也是需要檢查owner task所在cpu的resched情況。畢竟當(dāng)前任務(wù)如果有調(diào)度需求，無論reader持鎖還是writer持鎖場(chǎng)景都要停止自旋。

F、在reader-owned場(chǎng)景中，由于無法判定臨界區(qū)reader們的執(zhí)行狀態(tài)，因此rt線程的樂觀自旋需要更加的謹(jǐn)慎，畢竟有可能自旋的rt線程和臨界區(qū)的reader在一個(gè)CPU上從而導(dǎo)致活鎖現(xiàn)象。當(dāng)然也不能禁止rt線程的自旋，畢竟在臨界區(qū)為空的情況下，rt自旋會(huì)有一定的收益的。允許rt線程自旋的場(chǎng)景有兩個(gè)：

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

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

十三、關(guān)于handoff

1、設(shè)置handoff標(biāo)記

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

無論是reader還是writer，如果喚醒后持鎖失敗，并且等待時(shí)間已經(jīng)超過了RWSEM_WAIT_TIMEOUT，這時(shí)候就會(huì)設(shè)置handoff bit，防止等待隊(duì)列的waiter餓死。具體設(shè)置handoff bit的場(chǎng)景如下：

2、清除handoff標(biāo)記

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

3、確保鎖的所有權(quán)遞交給top waiter

十四、結(jié)論

標(biāo)準(zhǔn)linux內(nèi)核的讀寫鎖是在公平性、吞吐量和延遲選擇了比較均衡的策略，這樣的策略在手機(jī)平臺(tái)上（特別是重載場(chǎng)景下）不能算是“優(yōu)秀”，只能是合格吧。實(shí)際上，在手機(jī)用戶交互場(chǎng)景中，我們更期望是確保用戶體驗(yàn)相關(guān)線程的持鎖時(shí)延，同時(shí)兼顧吞吐量。在這樣的背景下，OPPO內(nèi)核團(tuán)隊(duì)對(duì)linux中的讀寫鎖進(jìn)行了優(yōu)化，下一次有機(jī)會(huì)可以分享我們?cè)谧x寫鎖的持鎖時(shí)延方面做的改進(jìn)。