调度相关的重要数据结构

声明

下面的分析均基于Golang1.14版本。
以下数据结构均做了裁剪,只留了部分调度密切相关的重要结构。

一、G的定义

裁剪了大部分字段,后面填坑把其它字段的作用及用途整理。

type g struct {
 stack stack // offset known to runtime/cgo G的栈信息含栈的起始和终止地址
 m *m // current m; offset known to arm liblink 运行时绑定的M
 sched gobuf // 运行时的上下文
 goid int64 // g id 唯一的标识id
}
type stack struct {
 lo uintptr
 hi uintptr
}
type gobuf struct {
 sp uintptr // 当前的栈顶地址
 pc uintptr // 当前的PC值
 g guintptr
 ctxt unsafe.Pointer
 ret sys.Uintreg
 lr uintptr
 bp uintptr // for GOEXPERIMENT=framepointer
}

二、M的定义

同样裁剪了大量字段,后面把坑填上。

type m struct {
 g0 *g // goroutine with scheduling stack 每个m都会绑定一个g0 g0的栈不可扩容 g0的栈和线程的栈重合 运行调度其他g的代码时使用的g0的栈
 gsignal *g // signal-handling g
 tls [6]uintptr // thread-local storage (for x86 extern register) 通常会存当前正在运行的g的指针
 curg *g // current running goroutine
 p puintptr // attached p for executing go code (nil if not executing go code)
 oldp puintptr // the p that was attached before executing a syscall
 id int64
 locks int32 // 锁
 spinning bool // m is out of work and is actively looking for work
 alllink *m // on allm 所有m以链表的方式串联这里表示链表中下一个m
 schedlink muintptr // spinning自旋中的m也以链表的方式串联 这里表示下一个自旋的m
 lockedg guintptr
 syscalltick uint32 // 系统调用时 用来标识陷入系统调用的时间
 freelink *m // on sched.freem // 所有的空闲的m以链表的方式串联 这里表示下一个空闲的m
 mOS // 绑定的物理线程的数据结构
}

三、P的定义

type p struct {
 id int32
 status uint32 // one of pidle/prunning/...
 link puintptr // 空闲的p以链表的方式串联 表示下一个空闲的p
 schedtick uint32 // incremented on every scheduler call
 syscalltick uint32 // incremented on every system call
 sysmontick sysmontick // last tick observed by sysmon
 m muintptr // back-link to associated m (nil if idle)
 goidcache uint64 // 缓存的goid的当前值
 goidcacheend uint64 // 缓存goid的最大值
 // Queue of runnable goroutines. Accessed without lock.
 runqhead uint32
 runqtail uint32
 runq [256]guintptr // 保存的该P上的可运行的G的队列
 runnext guintptr // 表示下一个要运行的G 通常newproc产生的g会放在这里
 // Available G's (status == Gdead)
 gFree struct {
 gList
 n int32
 }
}

四、sched变量

type schedt struct {
goidgen uint64
// allm idlem freem 链表是全局变量均需考虑同步
midle muintptr // idle m's waiting for work 空闲状态m链表中的首个m地址
nmidle int32 // number of idle m's waiting for work //空闲状态m的数量
nmidlelocked int32 // number of locked m's waiting for work
mnext int64 // number of m's that have been created and next M ID // 当前m的数量和下一个m的ID
maxmcount int32 // maximum number of m's allowed (or die) // 允许的m的最大数量

// 空闲p以链表的方式存储 注意同步读写
pidle puintptr // idle p's 空闲的p的链表的首个元素
npidle uint32 // 空闲p的数量
// nmspinning 表示当前处于自旋状态的p的数量(正在执行findrunnable函数)
nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.
// Global runnable queue.
runq gQueue // 全局的runnable状态的G 当p的队列满了时会将p放入该队列中
runqsize int32
// disable controls selective disabling of the scheduler.
//
// Use schedEnableUser to control this.
//
// disable is protected by sched.lock.
disable struct {
 // user disables scheduling of user goroutines.
 user bool
 runnable gQueue // pending runnable Gs
 n int32 // length of runnable
}
// Global cache of dead G's.
gFree struct {
 lock mutex
 stack gList // Gs with stacks
 noStack gList // Gs without stacks
 n int32
}
// Central cache of sudog structs.
sudoglock mutex
sudogcache *sudog
// Central pool of available defer structs of different sizes.
deferlock mutex
deferpool [5]*_defer
// freem is the list of m's waiting to be freed when their
// m.exited is set. Linked through m.freelink.
freem *m // 空闲的m以链表的方式串联 这里表示m空闲链表的首个m

}

其它全局数据

 allm *m // 所有m以链表的方式链接在一起 m.alllink表示下一个m
 // 所有p都放在该数组中 通常等于CPU核心数 在初始化时确定
 allp []*p // len(allp) == gomaxprocs; may change at safe points, otherwise immutable
 allgs []*g // 管理所有的g

关于GPM的数量

1.P的数量,P的数量通常等于CPU的数量,在Go程序初始化时创建,且通常不增不减。
2.G的数量,G在newproc函数(即go func(){})中可能会创建,当G对应的函数执行完成后,G不会释放,而是缓存起来,当需要时则优先从缓存中拿。
3.M的数量,当G进入可运行状态时,如果有空闲的P则可能会创建M来执行G。当M陷入系统调用或者cgo时,会剥夺M P的绑定,当退出系统调用后,不会释放M,而是等待空闲的P进行绑定,因此M的数量是不定的。

一些特例

1.特殊的线程sysmon,除该线程外其它物理线程均和m绑定,一一对应。
2.m0,m0是特殊的M,通常执行main函数,且还有其它特定的用途。
3.g0,每个m都有一个g0,g0通常会分配更大的栈,且它的栈不会扩容(普通的g的栈初始大小为2K,根据需要扩容)。g0通常执行调度相关代码,和普通的g的扩容的代码。g0的栈和物理线程的栈进行绑定,物理线程的栈即g0的栈,当使用cgo是,g0栈绑定到物理线程,如果不使用cgo则是物理线程的栈绑定到g0的栈(区别在于栈的位置和栈的大小)。
4.为什么使用cgo时使用物理线程的栈?因为cgo代码通常是别的语言所写,调用cgo时,使用的是g0的栈,如果该栈和物理线程大小不等,则可能出现库在别的语言可以正常调用,在golang中出现栈过小调用失败的情况。

本文来自:简书

感谢作者:不争_900c

查看原文:调度相关的重要数据结构

• 编辑
• 预览