go中的sync.RWMutex源码解读

• 读写锁
  • 前言
  • 什么是读写锁
  • 看下实现
  • 读锁
    • RLock
    • RUnlock
  • 写锁
    • Lock
    • Unlock
  • 问题要论
    • 写操作是如何阻止写操作的
    • 写操作是如何阻止读操作的
    • 读操作是如何阻止写操作的
    • 为什么写锁定不会被饿死
    • 两个读锁之间穿插了一个写锁
  • 参考

读写锁

前言

本次的代码是基于go version go1.13.15 darwin/amd64

什么是读写锁

读写锁类比于互斥锁，锁的粒度更小了。互斥锁，我们知道，一个资源被一把互斥锁，锁住了，另外的goroutine，在锁定期间，必定不能操作。

读写锁就不同了：

写锁需要阻塞写锁：一个协程拥有写锁时，其他协程写锁定需要阻塞

写锁需要阻塞读锁：一个协程拥有写锁时，其他协程读锁定需要阻塞

读锁需要阻塞写锁：一个协程拥有读锁时，其他协程写锁定需要阻塞

读锁不能阻塞读锁：一个协程拥有读锁时，其他协程也可以拥有读锁

看下实现

RWMutex提供4个简单的接口来提供服务：

RLock()：读锁定
RUnlock()：解除读锁定
Lock(): 写锁定，与Mutex完全一致
Unlock()：解除写锁定，与Mutex完全一致

看下具体的实现

type RWMutex struct {
	w           Mutex  // 用于控制多个写锁，获得写锁首先要获取该锁，如果有一个写锁在进行，那么再到来的写锁将会阻塞于此
	writerSem   uint32 // 写阻塞等待的信号量，最后一个读者释放锁时会释放信号量
	readerSem   uint32 // 读阻塞的协程等待的信号量，持有写锁的协程释放锁后会释放信号量
	readerCount int32  // 记录读者个数
	readerWait  int32  // 记录写阻塞时读者个数
}

读锁

RLock

const rwmutexMaxReaders = 1 << 30

// 读加锁
// 增加读操作计数，即readerCount++
// 阻塞等待写操作结束(如果有的话)
func (rw *RWMutex) RLock() {
	// 竞态检测
	if race.Enabled {
		_ = rw.w.state
		race.Disable()
	}
	// 当有之前有写锁的时候，写锁会先将readerCount减去rwmutexMaxReaders的值
	// 这样当有写操作在进行的时候这个值就是一个负数
	// 读操作根据这个来判断是否要将自己阻塞

	// 如果之前没有写锁，那么readerCount的值将大于等于0
	// 写锁同样根据这个值来判断在本次写锁之前是已经有读锁存在了

	// 首先通过atomic的原子性使readerCount+1
	// 1、如果readerCount<0。说明写锁已经获取了，那么这个读锁需要等待写锁的完成
	// 2、如果readerCount>=0。当前读直接获取锁
	if atomic.AddInt32(&rw.readerCount, 1) < 0 {
		// 当前有个写锁, 读操作阻塞等待写锁释放
		runtime_SemacquireMutex(&rw.readerSem, false, 0)
	}
	// 是否开启检测race
	if race.Enabled {
		race.Enable()
		race.Acquire(unsafe.Pointer(&rw.readerSem))
	}
}

梳理下流程：

1、首先当有写操作的时候，会先将readerCount减去rwmutexMaxReaders的值，这在写锁定(Lock())中可以看到；

2、原子的修改readerCount，如果结果小于0说明有写锁存在，需要阻塞读锁；

3、通过runtime_SemacquireMutex将当前的读锁加入到阻塞队列的尾部。

RUnlock

// 减少读操作计数，即readerCount--
// 唤醒等待写操作的协程（如果有的话）
func (rw *RWMutex) RUnlock() {
	// 是否开启检测race
	if race.Enabled {
		_ = rw.w.state
		race.ReleaseMerge(unsafe.Pointer(&rw.writerSem))
		race.Disable()
	}
	// 首先通过atomic的原子性使readerCount-1
	// 1.若readerCount大于0, 证明当前还有读锁, 直接结束本次操作
	// 2.若readerCount小于0, 证明已经没有读锁, 但是还有因为读锁被阻塞的写锁存在
	if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
		// 尝试唤醒被阻塞的写锁
		rw.rUnlockSlow(r)
	}
	// 是否开启检测race
	if race.Enabled {
		race.Enable()
	}
}

func (rw *RWMutex) rUnlockSlow(r int32) {
	// 判断RUnlock被过多使用了
	if r+1 == 0 || r+1 == -rwmutexMaxReaders {
		race.Enable()
		throw("sync: RUnlock of unlocked RWMutex")
	}
	// readerWait--操作，如果readerWait--操作之后的值为0，说明，写锁之前，已经没有读锁了
	// 通过writerSem信号量，唤醒队列中第一个阻塞的写锁
	if atomic.AddInt32(&rw.readerWait, -1) == 0 {
		// 唤醒一个写锁
		runtime_Semrelease(&rw.writerSem, false, 1)
	}
}

梳理下流程：

1、首先还是操作readerCount，对进行--操作；

• 1、如果操作之后的值大于0，说明还有读锁存在，直接结束本次操作；
• 2、如果操作之后值小于0，说明还有写锁存在，尝试在最后一个读锁完成的时候去唤醒写锁；

2、readerWait--操作，如果readerWait--操作之后的值为0，说明，写锁之前，已经没有读锁了；

3、通过信号量唤醒队列中第一个被阻塞的写锁。

写锁

Lock

// 获取互斥锁
// 阻塞等待所有读操作结束（如果有的话）
func (rw *RWMutex) Lock() {
	if race.Enabled {
		_ = rw.w.state
		race.Disable()
	}
	// 获取互斥锁
	rw.w.Lock()

	// 原子的修改readerCount的值，直接将readerCount减去rwmutexMaxReaders
	// 说明，有写锁进来了，这在上面的读锁中也有体现
	r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
	// 当r不为0说明，当前写锁之前有读锁的存在
	// 修改下readerWait，也就是当前写锁需要等待的读锁的个数
	if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
		// 阻塞当前写锁
		runtime_SemacquireMutex(&rw.writerSem, false, 0)
	}
	if race.Enabled {
		race.Enable()
		race.Acquire(unsafe.Pointer(&rw.readerSem))
		race.Acquire(unsafe.Pointer(&rw.writerSem))
	}
}

梳理下流程：

1、修改下readerCount的数量，直接减去rwmutexMaxReaders；

2、判断当前写锁之前，是否有读锁的存在；

我们知道，写操作要等待读操作结束后才可以获得锁，写操作等待期间可能还有新的读操作持续到来，如果写操作等待所有读操作结束，很可能被饿死。然而，通过RWMutex.readerWait可完美解决这个问题。

写操作到来时，会把RWMutex.readerCount值拷贝到RWMutex.readerWait中，用于标记排在写操作前面的读者个数。

前面的读操作结束后，除了会递减RWMutex.readerCount，还会递减RWMutex.readerWait值，当RWMutex.readerWait值变为0时唤醒写操作。

写操作之后产生的读操作就会加入到readerCount，阻塞直到写锁释放。

3、如果有读锁，阻塞当前写锁；

Unlock

// 如果写锁未锁定，解锁将会触发panic

//一个锁定的互斥锁与一个特定的goroutine没有关联。
// 它允许一个goroutine锁定一个写锁然后
// 安排另一个goroutine解锁它。
func (rw *RWMutex) Unlock() {
	if race.Enabled {
		_ = rw.w.state
		race.Release(unsafe.Pointer(&rw.readerSem))
		race.Disable()
	}

	// 增加readerCount, 若超过读锁的最大限制, 触发panic
	// 和写锁定的-rwmutexMaxReaders，向对应
	r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
	if r >= rwmutexMaxReaders {
		race.Enable()
		throw("sync: Unlock of unlocked RWMutex")
	}
	// 如果r>0，说明当前写锁后面，有阻塞的读锁
	// 然后，通过信号量一一释放阻塞的读锁
	for i := 0; i < int(r); i++ {
		runtime_Semrelease(&rw.readerSem, false, 0)
	}
	// 释放互斥锁
	rw.w.Unlock()
	if race.Enabled {
		race.Enable()
	}
}

梳理下流程：

1、首先修改readerCount的值，加上rwmutexMaxReaders，和上文的-rwmutexMaxReaders相呼应；

2、然后判断后面是否有读锁被阻塞，如果有一一唤醒。

问题要论

写操作是如何阻止写操作的

读写锁包含一个互斥锁(Mutex)，写锁定必须要先获取该互斥锁，如果互斥锁已被协程A获取（或者协程A在阻塞等待读结束），意味着协程A获取了互斥锁，那么协程B只能阻塞等待该互斥锁。

所以，写操作依赖互斥锁阻止其他的写操作。

写操作是如何阻止读操作的

我们知道RWMutex.readerCount是个整型值，用于表示读者数量，不考虑写操作的情况下，每次读锁定将该值+1，每次解除读锁定将该值-1，所以readerCount取值为[0, N]，N为读者个数，实际上最大可支持2^30个并发读者。

当写锁定进行时，会先将readerCount减去2^{30，从而readerCount变成了负值，此时再有读锁定到来时检测到readerCount为负值，便知道有写操作在进行，只好阻塞等待。而真实的读操作个数并不会丢失，只需要将readerCount加上2}30即可获得。

所以，写操作将readerCount变成负值来阻止读操作的。

读操作是如何阻止写操作的

写操作到来时，会把RWMutex.readerCount值拷贝到RWMutex.readerWait中，用于标记排在写操作前面的读者个数。

前面的读操作结束后，除了会递减RWMutex.readerCount，还会递减RWMutex.readerWait值，当RWMutex.readerWait值变为0时唤醒写操作。

为什么写锁定不会被饿死

我们知道，写操作要等待读操作结束后才可以获得锁，写操作等待期间可能还有新的读操作持续到来，如果写操作等待所有读操作结束，很可能被饿死。然而，通过RWMutex.readerWait可完美解决这个问题。

写操作到来时，会把RWMutex.readerCount值拷贝到RWMutex.readerWait中，用于标记排在写操作前面的读者个数。

前面的读操作结束后，除了会递减RWMutex.readerCount，还会递减RWMutex.readerWait值，当RWMutex.readerWait值变为0时唤醒写操作。

两个读锁之间穿插了一个写锁

type test struct {
	data map[string]string
	r    sync.RWMutex
}

func (t test) read() {
	t.r.RLock()
	t.r.Lock()
	fmt.Println(t.data)
	t.r.Unlock()
	t.r.RUnlock()
}

上面的代码将会发什么？

deadlock!

分析下原因

1、读锁是会阻塞写锁的，上面的读锁已经上锁了；

2、后面的写锁来加锁。发现已经有读锁了，然后使用信号量阻塞当前的写锁，等待读锁解锁时被唤醒；

3、然后这个写锁马上解锁，但是当前的写锁，一直在等待被信号量唤醒，读锁的解锁又一直在等待写锁的解锁；

4、然后就死循环，deadlock。

参考

【Package race】https://golang.org/pkg/internal/race/

【sync.RWMutex源码分析】http://liangjf.top/2020/07/20/141.sync.RWMutex源码分析/

【剖析Go的读写锁】http://zablog.me/2017/09/27/go_sync/

【《Go专家编程》GO 读写锁实现原理剖析】https://my.oschina.net/renhc/blog/2878292

本文作者：liz

本文链接：https://boilingfrog.github.io/2021/03/17/sync.RWMutex/

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。