<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
go RWMutex的實現範例
2022-03-14 13:01:27
Overview
go 裡面的 rwlock 是 write preferred 的，可以避免寫鎖飢餓。
讀鎖和寫鎖按照先來後到的規則持有鎖，一旦有協程持有了寫鎖，後面的協程只能在寫鎖被釋放後才能得到讀鎖。
同樣，一旦有 >= 1 個協程寫到了讀鎖，只有等這些讀鎖全部釋放後，後面的協程才能拿到寫鎖。
下面瞭解一下 Go 的 RWMutex 是如何實現的吧，下面的程式碼取自 go1.17.2/src/sync/rwmutex.go，並刪減了 race 相關的程式碼。
PS: rwmutex 的程式碼挺短的，其實讀原始碼也沒那麼可怕...
RWMutex 的結構
RWMutex 總體上是通過: 普通鎖和條件變數來實現的
type RWMutex struct {
w Mutex // held if there are pending writers
writerSem uint32 // semaphore for writers to wait for completing readers
readerSem uint32 // semaphore for readers to wait for completing writers
readerCount int32 // number of pending readers
readerWait int32 // number of departing readers
}
Lock
func (rw *RWMutex) Lock() {
// First, resolve competition with other writers.
rw.w.Lock()
// Announce to readers there is a pending writer.
r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
// Wait for active readers.
if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
runtime_SemacquireMutex(&rw.writerSem, false, 0)
}
}
Unlock
const rwmutexMaxReaders = 1 << 30
func (rw *RWMutex) Unlock() {
// Announce to readers there is no active writer.
r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
// Unblock blocked readers, if any.
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0)
}
// Allow other writers to proceed.
rw.w.Unlock()
}
RLock
func (rw *RWMutex) RLock() {
if atomic.AddInt32(&rw.readerCount, 1) < 0 {
// A writer is pending, wait for it.
runtime_SemacquireMutex(&rw.readerSem, false, 0)
}
}
RUnlock
func (rw *RWMutex) RUnlock() {
if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
// Outlined slow-path to allow the fast-path to be inlined
rw.rUnlockSlow(r)
}
}
func (rw *RWMutex) rUnlockSlow(r int32) {
// A writer is pending.
if atomic.AddInt32(&rw.readerWait, -1) == 0 {
// The last reader unblocks the writer.
runtime_Semrelease(&rw.writerSem, false, 1)
}
}
Q1: 多個協程並行拿讀鎖，如何保證這些讀鎖協程都不會被阻塞？
func (rw *RWMutex) RLock() {
if atomic.AddInt32(&rw.readerCount, 1) < 0 {
// A writer is pending, wait for it.
runtime_SemacquireMutex(&rw.readerSem, false, 0)
}
}
拿讀鎖時，僅僅會增加 readerCount，因此讀鎖之間是可以正常並行的
Q2: 多個協程並行拿寫鎖，如何保證只會有一個協程拿到寫鎖？
func (rw *RWMutex) Lock() {
// First, resolve competition with other writers.
rw.w.Lock()
// Announce to readers there is a pending writer.
r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
// Wait for active readers.
if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
runtime_SemacquireMutex(&rw.writerSem, false, 0)
}
}
拿寫鎖時，會獲取 w.Lock，自然能保證同一時間只會有一把寫鎖
Q3: 在讀鎖被拿到的情況下，新協程拿寫鎖，如果保證寫鎖現成會被阻塞？
func (rw *RWMutex) Lock() {
// First, resolve competition with other writers.
rw.w.Lock()
// Announce to readers there is a pending writer.
r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
// Wait for active readers.
if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
runtime_SemacquireMutex(&rw.writerSem, false, 0)
}
}
假設此時有 5 個協程拿到讀鎖，則 readerCount = 5，假設 rwmutexMaxReaders = 100。
此時有一個新的協程 w1 想要拿寫鎖。
在執行
r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
後， rw.readerCount = -95，r = 5。
在執行
atomic.AddInt32(&rw.readerWait, r)
後，rw.readerWait = 5。
readerWait 記錄了在獲取寫鎖的這一瞬間有多少個協程持有讀鎖。這一瞬間之後，就算有新的協程嘗試獲取讀鎖，也只會增加 readerCount ，而不會動到 readerWait。
之後執行 runtime_SemacquireMutex() 睡在了 writerSem 這個號誌上面。
Q4: 在讀鎖被拿到的情況下，新協程拿寫鎖被阻塞，當舊有的讀鎖協程全部釋放，如何喚醒等待的寫鎖協程
func (rw *RWMutex) RUnlock() {
if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
// Outlined slow-path to allow the fast-path to be inlined
rw.rUnlockSlow(r)
}
}
func (rw *RWMutex) rUnlockSlow(r int32) {
// A writer is pending.
if atomic.AddInt32(&rw.readerWait, -1) == 0 {
// The last reader unblocks the writer.
runtime_Semrelease(&rw.writerSem, false, 1)
}
}
繼續上一步的場景，每當執行 RUnlock 時，readerCount 都會減去1。當 readerCount 為負數時，意味著有協程正在持有或者正在等待持有寫鎖。
之前的五個讀協程中的四個，每次 RUnlock() 之後，readerCount = -95 - 4 = -99，readerWait = 5 - 4 = 1。
當最後一個讀協程呼叫 RUnlock() 之後，readerCount 變成了 -100，readerWait 變成 0，此時會喚醒在 writerSem 上沉睡的協程 w1。
Q5: 在寫鎖被拿到的情況下，新協程拿讀鎖，如何讓新協程被阻塞？
func (rw *RWMutex) RLock() {
if atomic.AddInt32(&rw.readerCount, 1) < 0 {
// A writer is pending, wait for it.
runtime_SemacquireMutex(&rw.readerSem, false, 0)
}
}
繼續上面的場景，readerCount = -100 + 1 = -99 < 0。
新的讀協程 r1 被沉睡在 readerSem 下面。
假設此時再來一個讀協程 r2，則 readerCount = -98，依舊沉睡。
Q6: 在寫鎖被拿到的情況下，新協程拿讀鎖，寫鎖協程釋放，如何喚醒等待的讀鎖協程？
繼續上面的場景，此時協程 w1 釋放寫鎖
func (rw *RWMutex) Unlock() {
// Announce to readers there is no active writer.
r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
// Unblock blocked readers, if any.
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0)
}
// Allow other writers to proceed.
rw.w.Unlock()
}
在執行
atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
後，r = readerCount = -98 + 100 = 2，代表此時有兩個讀協程 r1 和 r2 在等待
ps: 如果此時有一些新的協程想要拿讀鎖，他會因為 readerCount = 2 + 1 = 3 > 0 而順利執行下去，不會被阻塞
之後 for 迴圈執行兩次，將協程 r1 和 協程 r2 都喚醒了。
Q7: 在寫鎖被拿到的情況下，有兩個協程分別去搶讀鎖和寫鎖，當寫鎖被釋放時，這兩個協程誰會勝利？
func (rw *RWMutex) Unlock() {
// Announce to readers there is no active writer.
r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
// Unblock blocked readers, if any.
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0)
}
// Allow other writers to proceed.
rw.w.Unlock()
}
由於是先喚醒讀鎖，再呼叫 w.Unlock() ，因此肯定是讀協程先勝利！
認為寫的比較巧妙的兩個點
readerCount 與 rwmutexMaxReaders 的糾纏
通過
readerCount + rwmutexMaxReaders以及readerCount - rwmutexMaxReaders這兩個操作可以得知當前是否有協程等待/持有寫鎖以及當前等待/持有讀鎖的協程數量readerCount 與 readerWait 的糾纏
在 Lock() 時直接將 readerCount 的值賦給 readerWait，在 readerWait = 0 而非 readerCount = 0 是喚醒寫協程，可以避免在 Lock() 後來達到的讀協程先於寫協程被執行。
到此這篇關於go RWMutex的實現範例的文章就介紹到這了,更多相關go RWMutex內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！
相關文章
-
黑科技的輕簡出行，告別「電量焦慮症」：Anker氮化鎵超能充系列
综合看Anker超能充系列的性价比很高，并且与不仅和iPhone12/苹果<em>Mac</em>Book很配，而且适合多设备充电需求的日常使用或差旅场景，不管是安卓还是Switch同样也能用得上它，希望这次分享能给准备购入充电器的小伙伴们有所
2021-06-01 09:31:42
-
吳亦凡廠牌首秀，L4WUDU居然忘詞了，Rapper和明星比還是有差距！
除了L4WUDU与吴亦凡已经多次共事，成为了明面上的厂牌成员，吴亦凡还曾带领20XXCLUB全队参加2020年的一场音乐节，这也是20XXCLUB首次全员合照，王嗣尧Turbo、陈彦希Regi、<em>Mac</em> Ova Seas、林渝植等人全部出场。然而让
2021-06-01 09:31:34
-
IPFS、Chia、Bzz和ICP挖礦該怎麼選？哪一個更有優勢？
目前应用IPFS的机构：1 谷歌<em>浏览器</em>支持IPFS分布式协议 2 万维网 (历史档案博物馆)数据库 3 火狐<em>浏览器</em>支持 IPFS分布式协议 4 EOS 等数字货币数据存储 5 美国国会图书馆，历史资料永久保存在 IPFS 6 加
2021-06-01 09:31:24
-
有哪些事是買了雪佛蘭後才知道的？美事偷著樂，開拓者車主隨聊
开拓者的车机是兼容苹果和<em>安卓</em>，虽然我不怎么用，但确实兼顾了我家人的很多需求：副驾的门板还配有解锁开关，有的时候老婆开车，下车的时候偶尔会忘记解锁，我在副驾驶可以自己开门：第二排设计很好，不仅配置了一个很大的
2021-06-01 09:30:48
-
iPhone12在618最新定價，跌價幅度超過1400元，還等iPhone13嗎？
不仅是<em>安卓</em>手机，苹果手机的降价力度也是前所未有了，iPhone12也“跳水价”了，发布价是6799元，如今已经跌至5308元，降价幅度超过1400元，最新定价确认了。iPhone12是苹果首款5G手机，同时也是全球首款5nm芯片的智能机，它
2021-06-01 09:30:45