go读写锁

go读写锁

互斥锁每次只让一 g通过,去读写数据。但是读数据操作,并发其实没有问题。所以诞生了 读写锁。

读协程可以并发,一起读。但是 写协程还是要走互斥锁,只能一个个通过。

先加了读锁

先加了读锁。那么写的协程,就需要去休眠队列中等待。一直到读锁都释放。

先加了写锁

这个时候,不管再来 写协程还是读协程,都去休眠队列等待。

小结:

  没有加写锁时,多个协程都可以加读锁
  加了写锁时,无法加读锁,读协程排队等待
  加了读锁,写锁排队等待

定义

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 atomic.Int32 // number of pending readers
	readerWait  atomic.Int32 // number of departing readers
}

w:互斥锁作为写锁
writerSem:作为写协程队列
readerSem:作为读协程队列
readerCount: 正值:正在读的协程 负值:加了写锁
readerWait:写锁应该等待读协程个数

有三个sema队列了,w本身底层有一个,readerSemwriterSem

运行逻辑

当锁是一个初始化的状态,来了一个写协程

`rwmutexMaxReaders` 是一个非常大的常量

把readerCount 改成了一个 很大的负数

加写锁,有读协程已经在读了

来了写锁后,把 readerCount 也减去了一个很大的数,但是 3还是能从这个值中体现。
但是,当再有 读的g过来时候,发现readerCount 为负数,就会去readSem中休眠。

代码实现

读锁

加锁

func (rw *RWMutex) RLock() {
    
    // 将readerCount+1,发现还是负的,就去休眠,说明有写锁在等待
	if rw.readerCount.Add(1) < 0 {
		runtime_SemacquireRWMutexR(&rw.readerSem, false, 0)
	}
    // 如果不是负数,则加锁成功,去读数据
}

小结:

将给readerCount无脑加-
如果readerCount是正数,加锁成功
如果readerCount是负数,说明被加了写锁,陷入`readerSem`

解锁

func (rw *RWMutex) RUnlock() {
	// 将 readerCount 减去1, 如果 r 小于0,说明有写协程 在等待
	if r := rw.readerCount.Add(-1); r < 0 {
		// Outlined slow-path to allow the fast-path to be inlined
		rw.rUnlockSlow(r)
	}
}

func (rw *RWMutex) rUnlockSlow(r int32) {
    
    // readerWait  写锁应该等待读协程个数 减去1(自身) 之后,
    //如果是 0,说明没有 读协程在读取数据了 ,就去 `runtime_Semrelease `唤醒换一个写协程
	if rw.readerWait.Add(-1) == 0 {
		// The last reader unblocks the writer.
		runtime_Semrelease(&rw.writerSem, false, 1)
	}
}

读锁在解锁时候,去判断了 readerCount 是否小于0 是否有写协程在等待;然后再释放写协程,又判断了 readerWait 是否等于0,因为大于0,说明还有读协程。

小结:

  给readerCountit减1
  如果readerCount是正数,解锁成功,没有写协程在排队
  如果readerCount是负数,有写锁在排队
  如果自己是readerWait的最后一个,唤醒写协程

问题: 但是读锁在加锁时候,并没有 给 readerWait加值,这里判断是否有效呢 ?

写锁

加锁
func (rw *RWMutex) Lock() {

	rw.w.Lock() // 先去加互斥锁,加上了再执行下面的逻辑,加不上直接去 w的sema中休眠了
	r := rw.readerCount.Add(-rwmutexMaxReaders) + rwmutexMaxReaders
    // 判断 r是否为0, 等于0 则直接加锁成功了。
	if r != 0 && rw.readerWait.Add(r) != 0 {
		runtime_SemacquireRWMutex(&rw.writerSem, false, 0)
	}
}

讲下这里不为0的情况,如果r不为0,比如r为2,则说明还有2个读协程在工作。

rw.readerWait.Add(r)这句代码,正好解释了上面的问题。这里给 readerWait 赋值了,所以读协程在解锁时候,判断这个值才有用。

如果不来写协程,那这个 readerWait 没有意义,因为这是判断是否释放写协程的。

那有没有lock()被两个 写协程 先后连续执行,让 r 的值为一个很大的负数?

不会。因为要先去加 互斥锁。一个写协程加上后,其他的写协程只能去 sema中等待。上篇有讲过。 所以上面有一个举例的图其实是有问题的。

小结加写锁:

先加mutex写锁,若已经被加写锁会阻塞等待
将readerCount变为负值,阻塞读锁的获取
计算需要等待多少个读协程释放
如果需要等待读协程释放,陷入writerSem

解写锁

func (rw *RWMutex) Unlock() {
	
	r := rw.readerCount.Add(rwmutexMaxReaders)
    // 去释放读协程,没有去释放 `writerSem`里面的写协程,因为这里面根本不会有休眠的写协程
	for i := 0; i < int(r); i++ {
		runtime_Semrelease(&rw.readerSem, false, 0) // 释放读协程
	}
	rw.w.Unlock() // 解锁 互斥锁,让互斥锁的sema等待队列中的协程,重新去竞争锁
}

小结 解写锁 :

  将readercount变为正值,允许读锁的获取

  释放在readerSem中等待的读协程 上面讲了,这个时候 writerSem 是空的 

  解锁mutex

适合场景

适合读多写少的场景,如果都是写的场景,其实和互斥锁一样。

热门相关:全系灵师:魔帝嗜宠兽神妃   百炼成仙   傲娇总裁:蜜宠小甜妻!   仙碎虚空   傲娇驾到,总裁别闹