golang mutex源码详细解析
Posted nogos
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了golang mutex源码详细解析相关的知识,希望对你有一定的参考价值。
目前golang的版本是1.12,其中的mutex是增加了普通模式和饥饿模式切换的优化版本,为了便于理解,这里先从上一个版本1.7版本的mutex开始分析,以后再对优化版本进行说明。
1.7版本Mutex实现
Mutex定义
// mutex是互斥锁
// mutex的零值是没有加锁的
//在使用之后不能被拷贝
type Mutex struct
state int32 //状态标识
sema uint32 //信号量
const (
mutexLocked = 1 << iota // mutex is locked
mutexWoken
mutexWaiterShift = iota
)
其中state是记录用来记录加锁状态的,将一个整型按位划分来表示不同的含义,从低到高分别为第1位到第32位,
- 第1位表示是否被锁住。
- 第2表示是否被唤醒。
- 第3位到第32位表示等待在mutex上协程数量。
其中sema是信号量,是一个非负数的全局变量,下面对信号量进行简单说明。
信号量
信号量是进程间通信处理同步互斥的机制,通过一个计数器来控制对共享资源的访问次数限制。例如一个办公室有两台打印机,有几十台电脑连上,这是同时只能允许两个电脑进行打印,而其他电脑必须排队等待完成后才能打印。
sema就是信号量,是一个非负数的全局变量,该变量有两个操作P和V,PV操作都是不可中断的。
P(S)
(1)执行S=S-1;
(2)进行以下判断:
- 如果S < 0,进入阻塞队列,直到满足S>=0,如果S >= 0, 直接返回
- 因此P操作执行一次意味着分配一个资源,如上打印机意味着是资源,当S小于0意味着没有可用资源了,只能一直等待,直到资源空闲出来时才能继续。
V(S)
(1)执行S=S+1;
(2)进行以下判断:
- 如果S > 0,直接返回 如果S <= 0, 释放阻塞队列中的第一个等待进程
- 因此V操作执行一次意味着释放一个资源,当S小于等于0时,意味着还有进程在请求资源,此时释放了一个资源,就需要从等待队列中拿出一个进程来使用此刻释放的资源。
golang中信号量操作
runtime_Semacquire
func runtime_Semacquire(s uint32),P操作,等待s大于等于0,源码在runtime/sema.go中
runtime_Semrelease
func runtime_Semrelease, V操作,阻塞等待被唤醒,目前版本在runtime/sema.go中(定义稍有不同了)。
直接使用信号量实现互斥锁
考虑下,如果直接用信号量来实现互斥,即新建一个sema=1,然后用PV操作runtime_Semacquire和runtime_Semrelease来实现,也可以做到当一次请求时,拿到资源进行执行,后续请求阻塞,进入等待队列,不考虑性能,按照这样简单的思路实现如下:
type Mutex struct
sema uint32
func NewMutex() *Mutex
var mu Mutex
mu.sema = 1 // 初始设置sema=1
return &mu
func (m *Mutex) Lock()
runtime_Semacquire(&m.sema)
func (m *Mutex2) Unlock()
runtime_Semrelease(&m.sema)
问题
当加锁一次,代码中解锁了两次, 会导致sema值变化而不提示任何错误,即这时sema=2,资源数量发生了变化,导致后续运行异常,所以多次解锁时需要返回异常。
通过加锁次数避免重复解锁
type Mutex struct
key int32
sema uint32
func (m *Mutex) Lock()
if atomic.AddInt32(&m.key, 1) == 1
// changed from 0 to 1; we hold lock
return
runtime_Semacquire(&m.sema)
func (m *Mutex) Unlock()
switch v := atomic.AddInt32(&m.key, -1);
case v == 0:
// changed from 1 to 0; no contention
return
case v == -1:
// changed from 0 to -1: wasn't locked
// (or there are 4 billion goroutines waiting)
panic("sync: unlock of unlocked mutex")
runtime_Semrelease(&m.sema)
这个解决方案除了解决了我们前面说的重复加锁的问题外,还对我们初始化工作做了简化,不需要构造函数了。
-
初始:key=0, sema = 0
-
Lock第一次:key+1=1返回,sema=0,即第一次不进行P操作,直接将key加1表示获取了锁。
-
Lock第二次:key=2,进行P操作,发现sema-1 =-1<0,阻塞等待获取锁。
当执行了一次Lock后,key=1,sema=0,执行以下操作时: -
Unlock第一次:key-1=0返回,sema=0,第一次解锁不执行V操作,直接key减1表示释放锁。
-
Unlock第二次:key-1=-1,表示解锁过了,返回异常。
当执行了两次Lock后,key=2,sema=-1,执行以下操作时: -
Unlock第一次:key-1=1,执行V操作runtime_Semrelease,发现sema+1=0,会阻塞直到唤醒了其他协程,然后返回。
简单来说,增加一个key变量后,sema=0表示有一个资源,跟只用信号量时sema=1含义一样,在golang mutex也是基于此实现的。
Mutex操作解读(最新版)
Lock
func (m *Mutex) Lock()
-----------------代码块1 start-----------------
// Fast path: grab unlocked mutex.
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked)
if race.Enabled
race.Acquire(unsafe.Pointer(m))
return
-----------------代码块1 end-----------------
awoke := false
iter := 0
for
-----------------代码块2 start-----------------
old := m.state
new := old | mutexLocked
if old&mutexLocked != 0
if runtime_canSpin(iter)
// Active spinning makes sense.
// Try to set mutexWoken flag to inform Unlock
// to not wake other blocked goroutines.
if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken)
awoke = true
runtime_doSpin()
iter++
continue
new = old + 1<<mutexWaiterShift
-----------------代码块2 end-----------------
-----------------代码块3 start-----------------
if awoke
// The goroutine has been woken from sleep,
// so we need to reset the flag in either case.
if new&mutexWoken == 0
panic("sync: inconsistent mutex state")
new &^= mutexWoken
-----------------代码块3 end-----------------
-----------------代码块4 start-----------------
if atomic.CompareAndSwapInt32(&m.state, old, new)
if old&mutexLocked == 0
break
runtime_Semacquire(&m.sema)
awoke = true
iter = 0
-----------------代码块4 start-----------------
if race.Enabled
race.Acquire(unsafe.Pointer(m))
将上面代码标注为4块,下面依次进行分析。对代码逻辑进行详细分析之前,先介绍下其中用到部分函数。
关键函数
race.Acquire
if race.Enabled
race.Acquire(unsafe.Pointer(m))
竞争检测逻辑。go中使用goroutine比较常见,在大型项目中可能会在多个goroutine中用到某个全局变量,如果有竞争就需要加锁操作。
runtime_canSpin
//go:linkname sync_runtime_canSpin sync.runtime_canSpin
func sync_runtime_canSpin(i int) bool
if i >= active_spin || ncpu <= 1 || gomaxprocs <= int32(sched.npidle+sched.nmspinning)+1
return false
if p := getg().m.p.ptr(); !runqempty(p)
return false
return true
判断是否需要自选,golang中自旋锁并不会一直自旋下去,在runtime包中runtime_canSpin方法做了一些限制, 传递过来的iter大等于4或者cpu核数小等于1,最大逻辑处理器大于1,至少有个本地的P队列,并且本地的P队列可运行G队列为空才会进行自旋。
runtime_doSpin
//go:linkname sync_runtime_doSpin sync.runtime_doSpin
func sync_runtime_doSpin()
procyield(active_spin_cnt)
进行自旋操作,会调用procyield函数,该函数也是汇编语言实现。函数内部循环调用PAUSE指令。PAUSE指令什么都不做,但是会消耗CPU时间,在执行PAUSE指令时,CPU不会对它做不必要的优化。
代码块1
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked)
if race.Enabled
race.Acquire(unsafe.Pointer(m))
return
如果state=0,即没有锁住、没有唤醒且没有等待队列,可直接拿到锁,将状态置为锁住并返回,这相当于是上面demo版中从key=0,sema=0的状态,变为key=1,seme=0的状态。
代码块2
//最新状态
old := m.state
new := old | mutexLocked
//已经被锁住
if old&mutexLocked != 0
//判断是否需要自选,这是在for循环中,iter次数可能已经超过不需要自旋了,或者其他条件
if runtime_canSpin(iter)
// 主动自旋是有意义的,因为会尝试唤醒锁,
//这样上个协程此时unlock的话,就不会唤醒其他协程
if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken)
//自己没有唤醒,且原状态没有唤醒,
//且有协程在排队且设置唤醒标识成功,
//说明上个的协程此时unlock了,
awoke = true
//自旋一段时间
runtime_doSpin()
iter++
continue
//不需要自旋,将state的等待队列数据加1
new = old + 1<<mutexWaiterShift
代码块3
if awoke
//代码块1中将awoke置为1了,标识被唤醒
//代码块1中只有设置了唤醒标识,awoke才会为true,因此不会new&mutexWoken == 0
if new&mutexWoken == 0
panic("sync: inconsistent mutex state")
//既然当前协程被唤醒了,需要将state置为未唤醒
new &^= mutexWoken
代码块4
//这里new有四种值
if atomic.CompareAndSwapInt32(&m.state, old, new)
if old&mutexLocked == 0
//没有锁住,直接返回
break
//当前锁住的,阻塞在此处等待,会让出cpu
runtime_Semacquire(&m.sema)
//从阻塞中返回,设置当前协程被唤醒了
awoke = true
iter = 0
Unlock
func (m *Mutex) Unlock()
//race检测
if race.Enabled
_ = m.state
race.Release(unsafe.Pointer(m))
// 判断是否多次解锁,多次解锁则抛出异常
new := atomic.AddInt32(&m.state, -mutexLocked)
if (new+mutexLocked)&mutexLocked == 0
panic("sync: unlock of unlocked mutex")
old := new
for
if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken) != 0
return
new = (old - 1<<mutexWaiterShift) | mutexWoken
if atomic.CompareAndSwapInt32(&m.state, old, new)
runtime_Semrelease(&m.sema)
return
old = m.state
for循环中,因为old在更新,第一个if语句会在以下两种情况时返回:
- 当前锁上没有协程在等待
- 当前锁已经被其他协程lock了或者唤醒了
第二个if语句,cas原子操作将等待协程数目减1,并设置唤醒标识,阻塞在runtime_Semrelease处,直到有其他协程被唤醒才返回。
看到这里,就可以知道,唤醒操作有两种:
(1)lock函数,执行自旋过程中主动唤醒自己,会执行到awoke = true相关代码;
(2)unlock函数,原协程设置唤醒标识,本协程被动唤醒,不会执行awoke = true相关代码。
以上是关于golang mutex源码详细解析的主要内容,如果未能解决你的问题,请参考以下文章
不得不知道的golang之sync.Mutex互斥锁源码分析