go读写锁

go读写锁

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

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

先加了读锁

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

先加了写锁

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

小结：

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

定义

type RWMutex struct {w           Mutex        // held if there are pending writerswriterSem   uint32       // semaphore for writers to wait for completing readersreaderSem   uint32       // semaphore for readers to wait for completing writersreaderCount atomic.Int32 // number of pending readersreaderWait  atomic.Int32 // number of departing readers}w：互斥锁作为写锁writerSem：作为写协程队列readerSem：作为读协程队列readerCount： 正值：正在读的协程 负值：加了写锁readerWait：写锁应该等待读协程个数

有三个sema队列了，w本身底层有一个，readerSem 和 writerSem。

运行逻辑当锁是一个初始化的状态，来了一个写协程

`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 inlinedrw.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

适合场景

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