原文地址:Goroutine调度时机-什么时候和什么情况下会发生调度?
Go调度器会在以下三种情况对goroutine进行调度:
-
goroutine执行某个操作因条件不满足需要等待而发生的调度。
-
goroutine主动调用Gosched()让出CPU而发生的调度。
-
goroutine运行时间太长或长时间处于系统调用中,被调度器剥夺运行权而发生的调度。
本文主要通过下面这个例子来分析第一种情况,也就是因阻塞而发生的被动调度,其它两种情况会在之后的文章中详聊。
代码案例如下:
package main
func start(c chan int) {
c <- 100
}
func main() {
c := make(chan int)
go start(c)
<-c
}
上述程序启动时,main goroutine会先创建一个无缓存的channel,之后启动一个goroutine,称之为g2,来向channel发送数据,main则去读取channel,在这两个goroutine对channel读写时,一定会发生阻塞,不是main读取阻塞就是g2写入阻塞。
先用gdb反汇编main,看下main反汇编代码:
0x44f4d0 <+0>: mov %fs:0xfffffffffffffff8,%rcx
0x44f4d9 <+9>: cmp 0x10(%rcx),%rsp
0x44f4dd <+13>: jbe 0x44f549 <main.main+121>
0x44f4df <+15>: sub $0x28,%rsp
0x44f4e3 <+19>: mov %rbp,0x20(%rsp)
0x44f4e8 <+24>: lea 0x20(%rsp),%rbp
0x44f4ed <+29>: lea 0xb36c(%rip),%rax
0x44f4f4 <+36>: mov %rax,(%rsp)
0x44f4f8 <+40>: movq $0x0,0x8(%rsp)
0x44f501 <+49>: callq 0x404330 <runtime.makechan> #创建channel
0x44f506 <+54>: mov 0x10(%rsp),%rax
0x44f50b <+59>: mov %rax,0x18(%rsp)
0x44f510 <+64>: movl $0x8,(%rsp)
0x44f517 <+71>: lea 0x240f2(%rip),%rcx
0x44f51e <+78>: mov %rcx,0x8(%rsp)
0x44f523 <+83>: callq 0x42c1b0 <runtime.newproc> #创建goroutine
0x44f528 <+88>: mov 0x18(%rsp),%rax
0x44f52d <+93>: mov %rax,(%rsp)
0x44f531 <+97>: movq $0x0,0x8(%rsp)
0x44f53a <+106>: callq 0x405080 <runtime.chanrecv1> #从channel读取数据
0x44f53f <+111>: mov 0x20(%rsp),%rbp
0x44f544 <+116>: add $0x28,%rsp
0x44f548 <+120>: retq
0x44f549 <+121>: callq 0x447390 <runtime.morestack_noctxt>
0x44f54e <+126>: jmp 0x44f4d0 <main.main>
可以看到创建goroutine的go关键字被翻译成对runtime.newproc的调用,之前聊《知道Go第一个Goroutine是如何创建的麽?》聊过这个函数,这次再来简单看下此函数的流程:
-
切换到g0栈。
扫描二维码关注公众号,回复: 13241293 查看本文章 -
分配g结构体对象。
-
初始化g对应的栈信息,并将参数拷贝到新g的栈上。
-
设置好g的sched成员,其包括调度g时所必须的sp、pc、bp等调度信息。
-
调用runqput将g放入运行队列。
-
返回。
前文聊的时候并未详细说明runqput是如何将g放入运行队列的,这次就来详细聊聊。
来看runtime/proc.go文件4746行代码分析runqput:
// runqput tries to put g on the local runnable queue.
// If next is false, runqput adds g to the tail of the runnable queue.
// If next is true, runqput puts g in the _p_.runnext slot.
// If the run queue is full, runnext puts g on the global queue.
// Executed only by the owner P.
func runqput(_p_ *p, gp *g, next bool) {
if randomizeScheduler && next && fastrand() % 2 == 0 {
next = false
}
if next {
//把gp放在_p_.runnext成员里,
//runnext成员中的goroutine会被优先调度起来运行
retryNext:
oldnext := _p_.runnext
if !_p_.runnext.cas(oldnext, guintptr(unsafe.Pointer(gp))) {
//有其它线程在操作runnext成员,需要重试
goto retryNext
}
if oldnext == 0 { //原本runnext为nil,所以没任何事情可做了,直接返回
return
}
// Kick the old runnext out to the regular run queue.
gp = oldnext.ptr() //原本存放在runnext的gp需要放入runq的尾部
}
retry:
//可能有其它线程正在并发修改runqhead成员,所以需要跟其它线程同步
h := atomic.LoadAcq(&_p_.runqhead) // load-acquire, synchronize with consumers
t := _p_.runqtail
if t - h < uint32(len(_p_.runq)) { //判断队列是否满了
//队列还没有满,可以放入
_p_.runq[t % uint32(len(_p_.runq))].set(gp)
// store-release, makes it available for consumption
//虽然没有其它线程并发修改这个runqtail,但其它线程会并发读取该值以及p的runq成员
//这里使用StoreRel是为了:
//1,原子写入runqtail
//2,防止编译器和CPU乱序,保证上一行代码对runq的修改发生在修改runqtail之前
//3,可见行屏障,保证当前线程对运行队列的修改对其它线程立马可见
atomic.StoreRel(&_p_.runqtail, t + 1)
return
}
//p的本地运行队列已满,需要放入全局运行队列
if runqputslow(_p_, gp, h, t) {
return
}
// the queue is not full, now the put above must succeed
goto retry
}
runqput的流程很清晰,先是尝试将gp放入_p_的本地运行队列,如果本地运行队列满了,则通过runqputslow将gp放入全局运行队列。
来看runtime/proc.go文件4784行代码,分析runqputslow:
// Put g and a batch of work from local runnable queue on global queue.
// Executed only by the owner P.
func runqputslow(_p_ *p, gp *g, h, t uint32) bool {
var batch [len(_p_.runq) / 2 + 1]*g //gp加上_p_本地队列的一半
// First, grab a batch from local queue.
n := t - h
n = n / 2
if n != uint32(len(_p_.runq) / 2) {
throw("runqputslow: queue is not full")
}
for i := uint32(0); i < n; i++ { //取出p本地队列的一半
batch[i] = _p_.runq[(h+i) % uint32(len(_p_.runq))].ptr()
}
if !atomic.CasRel(&_p_.runqhead, h, h + n) { // cas-release, commits consume
//如果cas操作失败,说明已经有其它工作线程从_p_的本地运行队列偷走了一些goroutine,所以直接返回
return false
}
batch[n] = gp
if randomizeScheduler {
for i := uint32(1); i <= n; i++ {
j := fastrandn(i + 1)
batch[i], batch[j] = batch[j], batch[i]
}
}
// Link the goroutines.
//全局运行队列是一个链表,这里首先把所有需要放入全局运行队列的g链接起来,
//减少后面对全局链表的锁住时间,从而降低锁冲突
for i := uint32(0); i < n; i++ {
batch[i].schedlink.set(batch[i+1])
}
var q gQueue
q.head.set(batch[0])
q.tail.set(batch[n])
// Now put the batch on global queue.
lock(&sched.lock)
globrunqputbatch(&q, int32(n+1))
unlock(&sched.lock)
return true
}
runqputslow先使用链表将从_p_的本地运行队列中取出来的一半连同gp串联起来,之后加锁成功后通过globrunqputbatch将该链表链入全局运行队列(全局运行队列是使用链表来实现的),runqputslow并未在一开始的时候就将全局运行队列锁住,而是等所有准备工作完成之后才锁住全局运行队列,这也是并发编程加锁的基本原则,也就是说要尽量减小锁的粒度,降低锁冲突的概率。
到这里呢,就聊完runqput是如何将g放入运行队列了,之后再来看main goroutine因读取channel而发生的阻塞流程。
从代码逻辑这边来看,是不知道main和g2谁先运行的,只是分析的话,就可以先来假设main创建完g2之后首先阻塞在读取channel操作上。
读取channel是通过调用runtime.chanrecv1实现的,本文主要关注的是读取过程中与调度相关的内容,具体细节是不关注的。
来看runtime/chan.go文件403行代码,来分析chanrecv1:
// entry points for <- c from compiled code
//go:nosplit
func chanrecv1(c *hchan, elem unsafe.Pointer) {
chanrecv(c, elem, true)
}
// runtime/chan.go : 415
func chanrecv(c *hchan, ep unsafe.Pointer, block bool) (selected, received bool) {
......
//省略部分的代码逻辑主要在判断读取操作是否可以立即完成,如果不能立即完成
//就需要把g挂在channel c的读取队列上,然后调用goparkunlock函数阻塞此goroutine
goparkunlock(&c.lock, waitReasonChanReceive, traceEvGoBlockRecv, 3)
......
}
chanrecv1直接调用chanrecv实现读取,chanrecv先验证channel中是否有数据可读,有则直接读取并返回,没有则需将当前goroutine挂入channel的读取队列之中,之后调用goparkunlock阻塞该goroutine。
来看runtime/proc.go文件304行代码,来分析goparkunlock:
// Puts the current goroutine into a waiting state and unlocks the lock.
// The goroutine can be made runnable again by calling goready(gp).
func goparkunlock(lock *mutex, reason waitReason, traceEv byte, traceskip int) {
gopark(parkunlock_c, unsafe.Pointer(lock), reason, traceEv, traceskip)
}
// runtime/proc.go : 276
// Puts the current goroutine into a waiting state and calls unlockf.
// If unlockf returns false, the goroutine is resumed.
// unlockf must not access this G's stack, as it may be moved between
// the call to gopark and the call to unlockf.
// Reason explains why the goroutine has been parked.
// It is displayed in stack traces and heap dumps.
// Reasons should be unique and descriptive.
// Do not re-use reasons, add new ones.
func gopark(unlockf func(*g, unsafe.Pointer) bool, lock unsafe.Pointer, reason waitReason, traceEv byte, traceskip int) {
......
// can't do anything that might move the G between Ms here.
mcall(park_m) //切换到g0栈执行park_m函数
}
goparkunlock直接调用gopark,gopark则调用mcall从main goroutine切到g0去执行park_m(mcall主要是保存当前goroutine现场,然后切到g0栈去调用作为参数传递给它的函数)。
来看runtime/proc.go文件2581行代码,来分析park_m:
// park continuation on g0.
func park_m(gp *g) {
_g_ := getg()
if trace.enabled {
traceGoPark(_g_.m.waittraceev, _g_.m.waittraceskip)
}
casgstatus(gp, _Grunning, _Gwaiting)
dropg() //解除g和m之间的关系
......
schedule()
}
park_m先将当前goroutine状态设置为_Gwaiting(因为当前goroutine正在等待其它goroutine往channel里写入数据),然后调用dropg接触g和m之间的关联,最后通过schedule进入调度循环。
schedule之前聊过,它会先从运行队列中挑出一个goroutine,之后调用gogo切到挑出的goroutine去运行。
因为main goroutine在读取channel被阻塞之前就已经将创建好的g2放入运行队列,所以此时schedule会将g2调度起来运行。
至此就完成一次从main到g2调度(当前场景假设只有一个工作线程在进行调度)。
g2入口函数是start,接下来反汇编start来g2写入channel阻塞流程。
start反汇编代码如下:
0x44f480 <+0>:mov %fs:0xfffffffffffffff8,%rcx
0x44f489 <+9>:cmp 0x10(%rcx),%rsp
0x44f48d <+13>:jbe 0x44f4c1 <main.start+65>
0x44f48f <+15>:sub $0x18,%rsp
0x44f493 <+19>:mov %rbp,0x10(%rsp)
0x44f498 <+24>:lea 0x10(%rsp),%rbp
0x44f49d <+29>:mov 0x20(%rsp),%rax
0x44f4a2 <+34>:mov %rax,(%rsp)
0x44f4a6 <+38>:lea 0x2d71b(%rip),%rax
0x44f4ad <+45>:mov %rax,0x8(%rsp)
0x44f4b2 <+50>:callq 0x404560 <runtime.chansend1> #写channel
0x44f4b7 <+55>:mov 0x10(%rsp),%rbp
0x44f4bc <+60>:add $0x18,%rsp
0x44f4c0 <+64>:retq
0x44f4c1 <+65>:callq 0x447390 <runtime.morestack_noctxt>
0x44f4c6 <+70>:jmp 0x44f480 <main.start>
可看到编译器将对channel发送操作翻译成对runtime.chansend1的调用。
来看runtime/chan.go文件124行代码分析chansend1:
// entry point for c <- x from compiled code
//go:nosplit
func chansend1(c *hchan, elem unsafe.Pointer) {
chansend(c, elem, true, getcallerpc())
}
// runtime/chan.go : 142
func chansend(c *hchan, ep unsafe.Pointer, block bool, callerpc uintptr) bool {
......
if sg := c.recvq.dequeue(); sg != nil {
// Found a waiting receiver. We pass the value we want to send
// directly to the receiver, bypassing the channel buffer (if any).
//可以直接发送数据给sg
send(c, sg, ep, func() { unlock(&c.lock) }, 3)
return true
}
......
}
// runtime/chan.go : 269
func send(c *hchan, sg *sudog, ep unsafe.Pointer, unlockf func(), skip int) {
......
goready(gp, skip+1)
}
// runtime/proc.go : 310
func goready(gp *g, traceskip int) {
systemstack(func() {
ready(gp, traceskip, true)
})
}
channel发送和读取流程类似,如能立即发送则立即发送并返回,反之需阻塞,在此场景中,因main goroutine此时正挂在channel读取队列上等待数据,所以直接调用send发送数据给main goroutine,send则调用goready切到g0栈,之后调用ready来唤醒sg对应的goroutine,也就是正在读channel的main goroutine。
来看runtime/proc.go文件639行代码来分析ready:
// Mark gp ready to run.
func ready(gp *g, traceskip int, next bool) {
......
// Mark runnable.
_g_ := getg()
......
// status is Gwaiting or Gscanwaiting, make Grunnable and put on runq
casgstatus(gp, _Gwaiting, _Grunnable)
runqput(_g_.m.p.ptr(), gp, next) //放入运行队列
if atomic.Load(&sched.npidle) != 0 && atomic.Load(&sched.nmspinning) == 0 {
//有空闲的p而且没有正在偷取goroutine的工作线程,则需要唤醒p出来工作
wakep()
}
......
}
ready先将需唤醒的goroutine状态设置为_Grunnable,之后将其放入运行队列之中来等待调度器的调度,如果当前有空闲的p并且没有工作线程正在尝试从各个工作线程的本地运行队列偷取goroutine(没有处于spinning状态的工作线程)的话,那就需要wakep将空闲的p叫起来工作。
至此,main goroutine已被放入运行队列,但还未被调度起来运行,而g2在向channel写入数据完成之后,就从ready返回并退出了,由《非main goroutine的退出流程和调度循环》一文可知,g2退出过程中会在goexit0中调用schedule进入下一轮调度,从而将刚刚放入运行队列的main goroutine调度起来运行。
以上仅为个人观点,不一定准确,能帮到各位那是最好的。
好啦,到这里本文就结束了,喜欢的话就来个三连击吧。
扫码关注公众号,获取更多优质内容。