Mutex概括

在这里插入图片描述

Mutex(Mutual exclusion),Go中Mutex的数据结构是这样的,因为足够简单,所以不需要额外的初始化,零值就是一个有效的互斥锁,处于Unlocked状态。state存储的是互斥锁的状态,加锁和解锁,都是通过atomic包提供的函数原子性,操作该字段。sema用作一个信号量,主要用于等待队列。
在这里插入图片描述

Mutex有两种模式,在正常模式下,一个尝试加锁的goroutine会先自旋四次,自旋锁(如果不成功就一直尝试),尝试通过原子操作获得锁,若几次自旋之后仍不能获得锁,则通过信号量排队等待。

在这里插入图片描述

所有等待者会按照先入先出FIFO的顺序排队。

在这里插入图片描述

但是当锁被释放,第一个等待者被唤醒后并不会直接拥有锁,而是需要和后来者竞争,也就是那些处于自旋阶段,尚未排队等待的goroutine。这种情况下后来者更有优势,一方面,它们正在CPU上运行,自然比刚被唤醒的goroutine更有优势,另一方面处于自旋状态的goroutine可以有很多,而被唤醒的goroutine每次只有一个,所以被唤醒的goroutine有很大概率拿不到锁。这种情况下它会被重新插入到队列的头部,而不是尾部

在这里插入图片描述

而当一个goroutine本次加锁等待时间超过了1ms后,它会把当前Mutex从正常模式切换至“饥饿模式”。
在这里插入图片描述

在饥饿模式下,Mutex的所有权从执行Unlock的goroutine,直接传递给等待队列头部的goroutine,后来者不会自旋,也不会尝试获得锁,即使Mutex处于Unlocked的状态。它们会直接到队列的尾部排队等待。

在这里插入图片描述

当一个等待者获得锁之后,它会在以下两种情况时,将Mutex由饥饿模式切换回正常模式。

  • 第一种情况是它的等待时间小于1ms,也就是它刚来不久
  • 第二种情况是它是最后一个等待者,等待队列已经空了,后面自然就没有饥饿的goroutine了

在这里插入图片描述

综上所述,在正常模式下自旋和排队是同时存在的,执行lock的goroutine会先一边自旋,尝试4次后如果还没拿到锁,就需要去排队等待了,这种排队之前先让大家来抢的模式,能够有更高的吞吐量,因为频繁的挂起,唤醒goroutine会带来较多的开销。但是又不能无限制的自旋,要把自旋的开销控制在较小的范围内,所以在正常模式下,Mutex有更好的性能。 但是可能会出现队列尾端的goroutine迟迟抢不到锁(尾端延迟)的情况。

在这里插入图片描述

而饥饿模式不再尝试自旋,所有goroutine都要排队,严格的FIFO,对于防止出现尾端延迟来讲特别重要。

Mutex.state状态标识

在这里插入图片描述

首先来看一下关于Mutex.state的几个常量定义,state是int32类型,其中第一个位用作锁状态标识,1表示已加锁,对应掩码常量为mutexLocked,第二位用于记录是否已有goroutine被唤醒了,1表示已唤醒,对应掩码常量为mutexWoken,第三位表示Mutex的工作模式,0代表正常模式,1代表饥饿模式,对应掩码常量为mutexStartving ,而常量mutexWaiterShift等于3,表示除了低三位以外,state的其它位用来记录有多少个等待者在排队。

在这里插入图片描述

来看一下lock和unlock的方法,精简掉了注释和部分race检测相关代码,两个方法中主要是通过atomic函数来实现了Fast path。相应的Slow path被单独放在了lockSlow和unlockSlow方法中。根据源码注释的说法,这样是为了便于编译器堆Fast path进行内联优化。

Lock的Fast path期望Mutex处于Unlocked状态,没有goroutine在排队,更不会饥饿,理想状态下,一个CAS操作就可以获得锁,但是如果CAS操作没能获得锁,就需要进入Slow path,也就是lockSlow方法。

Unlock方法同理,首先通过原子操作从state中减去mutexLocked,也就是释放锁,然后根据state的新值来判断是否需要执行Slow path。如果新值为0,也就意味着没有其他goroutine在排队, 所以不需要执行额外操作,如果新值不为0,那就需要进入slow path,看看是不是需要唤醒某个goroutine。lock和unlock的fast path就是这样,接下来展开slow path的主要逻辑。

Mutex源码剖析

在这里插入图片描述

当一个goroutine尝试给mutex加锁时,如果其他goroutine已经加了锁还没有释放,而且当前mutex工作在正常模式下,是不是就要开始自旋了呢?

在这里插入图片描述

不一定,因为如果当前是单核场景,自旋的goroutine在等待持有锁的goroutine释放锁,而持有锁的goroutine在等待自旋的goroutine让出CPU,这种情况下自旋是没有意义的。而且如果GOMAXPROCS=1,或者当前没有其它正在运行的P,也和单核场景类似,同样不需要自旋。除此之外,如果当前P的本地runq不为空,相较于自旋而言,切换到本地runq更有效率,所以为保障吞吐量也不会自旋。

最终,只有在多核场景下,且GOMAXPROCS>1,至少有一个其他的P处于running,当前P的本地runq为空的情况下,才可以自旋。

在这里插入图片描述

进入自旋的goroutine会先去争抢mutex的唤醒标识位(自旋G与等待队列第一个G就是在此竞争),设置mutexWoken标识位的目的是,在正常模式下,告知持有锁的goroutine,在unlock的时候不用再唤醒其他goroutine了,已经有goroutine在这里等待,以免唤醒太多的等待协程。mutex中的自旋,底层是通过procyield循环执行30次PAUSE,自旋次数上限为4,而且每自旋一次都要重新判断是否可以继续自旋。

在这里插入图片描述

如果锁被释放了,或者锁进入了饥饿模式,亦或者已经自旋了4次,都会结束自旋。结束自旋或者根本不用自旋的goroutine,就该尝试原子操作修改mutex的状态了。把此时mutex.state保存了old中,把要修改为的新state记为new。

  • 如果old处于饥饿模式或者加锁状态,goroutine就得去排队,所以在这些情况下排队规模要加1.
  • 如果是正常模式,就要尝试设置lock位,所以最后一位要置为1
  • 如果当前goroutine等待的时间已经超过1ms,而且锁还没被释放,就要将mutex的状态切换为饥饿模式,这里之所有还要求锁没被释放,是因为如果锁已经释放了,那怎么都得去抢一次啊,要是直接进入饥饿模式就只能去排队了。
  • 在执行原子操作修改state之前,若是当前goroutine持有唤醒标识的话,还要将唤醒标识位重置。

把排队规模和几个标志位都设置好以后,在执行原子操作修改state之前,若是当前goroutine持有唤醒标识的话,还要将唤醒标识位重置。因为接下来无论是要去抢锁,还是单纯的去排队,如果原子操作成功了,那么要么是成功抢到了锁,要么是成功进到了等待队列里。当前goroutine都不再是被唤醒的goroutine了,所以要释放唤醒标识。
在这里插入图片描述

而如果原子操作不成功,也就意味着其他goroutine在我们保存mutex.state到old以后,又修改了state的值,当前goroutine就要回过头去,继续从自旋检测这里开始再次尝试。所以也需要释放自己之前抢到的唤醒标识位,从头再来。

在这里插入图片描述

继续展开这个原子操作成功的分支,如果是抢锁操作成功了,那么加锁的slow path就可以宣告结束了。

如果是排队的规模设置成功了,还要决定是排在等待队列头部还是尾部,如果当前goroutine已经排过队,是在unlock中唤醒的,那就排在等待队列头部。

如果是第一次排队,就排到最后,并且从第一次排队开始记录当前goroutine的等待时间。

在这里插入图片描述

接下来就会让出,进到等待队列里面了(runtime_SemacquireMutex(&m.sema, queueLifo, 1)),队列里的goroutine被唤醒时(unlock),要从上次让出的地方(39行,runtime_SemacquireMutex的下面)开始继续执行,接下来会判断,如果mutex处在正常模式,那就接着从自旋开始抢锁,如果唤醒后的mutex处在饥饿模式,那就没有其他goroutine会和自己抢了,锁已经轮到自己这里,只需要把mutex.state中lock标识位设置为加锁,把等待队列规模减去1,再看看是不是要切换到正常模式,也就是自己的等待时间是不是小于1ms,或者等待队列已经空了,最后设置好mutex.state就一切ok了,这就是加锁操作的slow path。

在这里插入图片描述

接下来看unlock的slow path,进到unlock的slow path,说明除去lock标识为以外,剩下的位不全为0,如果处在正常模式,若等待队列为空,或已经有goroutine被唤醒或者获得了锁,或者锁进入了饥饿模式,那就不需要唤醒某个goroutine了,直接返回即可。否则就要尝试抢占mutexWoken标识位,获取唤醒一个goroutine的权利,抢占成功后,就会通过runtime_Semrelease函数唤醒一个goroutine,如果抢占不成功就进行循环尝试,直到等待队列为空,或已经有goroutine被唤醒或者获得了锁,或者锁进入了饥饿模式,则退出循环,而在饥饿模式下,后来的goroutine不会争抢锁,而是直接排队,锁的所有权是直接从执行unlock的goroutine,传递给等待队列中首个等待者的,所以不用抢占mutexWoken标识位。

第一个等待者唤醒后,会继承当前goroutine的时间片立刻开始运行,也就是继续lockSlow中这里,goroutine被唤醒以后的逻辑,这就是unlock的slow path。