Go: 互斥锁与饥饿
本文使用Go版本:1.13
在使用Golang开发时,当尝试获取一个永远也得不到的互斥锁时,它就可能发生饥饿问题。本文我们将研究Go1.8版本饥饿问题。该问题在Go1.9版本已经解决。
饥饿
为了更好解释互斥锁饥饿情况,我们将以以下示例讨论并演示其改进。
func main() {
done := make(chan bool, 1)
var mu sync.Mutex
// goroutine 1
go func() {
for {
select {
case <-done:
return
default:
mu.Lock()
time.Sleep(100*time.Microsecond)
mu.UnLock()
}
}
}
// goroutine 2
for i := 0; i < 10; i++ {
time.Sleep(100*time.Microsecond)
mu.Lock()
mu.UnLock()
}
done <- true
}
本示例使用了两个协程:
- 协程1长时间持有锁并迅速释放
- 协程2短暂持有锁并长时间释放
二者都有100微妙的周期,但协程1不断请求获取锁,可以预见的是其将不断持有该锁。
下面时使用Go1.8完成的示例,并打印协程2迭代10次之后锁分配情况:
每个goroutine获取锁情况:
g1: 7200216
g2: 10
可以看的第二个协程获取10次锁的时候,第一个协程获取锁的次数远超10次。我们来分析发生了什么。
首先,协程1获取锁并休眠100微秒。当第二个协程尝试获取锁时,将被加入锁队列(FIFO),且该协程将进入等待状态:
然后,当协程1完成它的工作时,将释放锁。并通知队列唤起协程2。协程2将被标记为可运行状态并等待调度器调起:
然而,当协程2正等待执行时,协程1将再次请求锁:
当协程2尝试获取锁时,将发现该锁已被持有并进入等待模式,如下图:
故而协程2能获取锁将取决于其在线程上运行所花费的时间。
现在的问题已经确定,让我们尝试解决它可行的方案。
桥接 VS 切换 && 自旋
有会多方式可以解决互斥锁,例如:
- 桥接。这是为提高吞吐量儿设计的。当锁释放时,它将唤醒第一个等待着,并且将锁给第一个传入的请求者或者当前等待着。
这就是Go1.8的设计方式,即我们最开始示例所看到。
- 切换。释放时,互斥锁将持有该锁,直到第一位等待着准备获取它。这种方式会减少吞吐量,因为即使有协程已经准备获取锁,锁也会互斥锁被持有。
我们能在Linux内核锁中找到这种逻辑。
饥饿状态是可能会出现的,因为该方式运行窃取锁。正在运行的任务会优先于即将被唤醒或已被唤 醒的协程获得锁。
窃取锁是一项重要的性能优化,因为等待唤醒的协程并获得锁可能会花费很多时间。在此期间,每个协程都会在该锁上停顿。
这会重新引入新的等待时间,因为一旦我们进行协程切换,其他协程就只能等待唤醒。
这种方式下,锁切换很好平衡两个协程之前锁的分配,但它也降低了性能,因为它会强制第一个协程等待锁即使它没有被持有。
- 自旋。互斥锁不同于自旋锁,它必须结合一些逻辑。当等待队列为空或当应用程序大量使用互斥锁时,自旋在这个时候是有用的。取消或唤起协程都有成本,并且可能比自旋等待下一个锁获取更慢。
Go1.8便使用了这种策略。当尝试获取一个已持有的锁时,如果本地队列为空并且处理器数量大于1,则协程将会自旋几次。当使用一个处理器处理自旋时,程序会处于阻塞状态。自旋过后,该协程将会停止。在程序大量使用锁的情况下,这是一种有效的方式。
饥饿模式
在Go1.9之前,Go结合了桥接于自旋模式。而Go1.9版本,Go通过添加新的饥饿模式来解决之前的问题,该模式将导致解锁模式期间的切换。所以等待的协程超过1毫秒,也成为有界等待,将被标记为饥饿。被标记为饥饿的协程,解锁时会将该锁交给第一位进入等待的协程。工作模式如下:
在饥饿模式下,自旋也可能会停止。因为传入的协程没有机会获取锁。
使用Go1.9版本在饥饿模式下运行之前的用例:
每个goroutine获取锁情况:
g1: 57
g2: 10
当前结果就比较公平了。
原文地址:medium.com/a-journey-with-go/go-mu...
译文地址:博客:Go: 互斥锁与饥饿
本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: