《也谈goroutine调度器》的评论

作者：affe

affe — Sat, 10 Oct 2020 07:03:21 +0000

”如果G被阻塞在某个system call操作上，那么不光G会阻塞，执行该G的M也会解绑P(实质是被sysmon抢走了)，与G一起进入sleep状态“ 感觉M不是进入sleep状态（而是blocked 状态，等待系统调用完成) 因为好像用户态线程没有sleep这个状态，而且如果调用blocking syscall 的话，M应当处于blocked的状态。

作者：bigwhite

bigwhite — Tue, 21 Apr 2020 01:15:47 +0000

why从GM到GPM？最权威的应该是GPM调度器设计和实现者的设计文档：https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit 。你也可以看看我翻译的这篇文章：《图解Go运行时调度器》- https://tonybai.com/2020/03/21/illustrated-tales-of-go-runtime-scheduler/ 从goroutine调度的设计视角去分析为什么会有GM，为什么会演化为GPM，解决的是什么问题。

作者：crazycn110

crazycn110 — Sat, 18 Apr 2020 16:30:30 +0000

GM为什么不如GPM，没有太理解。面试时候，还被问到了，直接就栽。

作者：瓦力

瓦力 — Sat, 07 Mar 2020 15:12:59 +0000

看的时候我也有这个疑问，难不成thread只管创建不管销毁嘛，搜了下后貌似对于thread的管理的确没有太多限制。这里有关于这个问题的讨论：
https://github.com/golang/go/issues/4056

作者：lostpg

lostpg — Sun, 05 Jan 2020 09:43:21 +0000

请问 G 的抢占调度那部分，
「可以看出，如果一个 G 任务运行 10ms，sysmon 就会认为其运行时间太久而发出抢占式调度的请求。一旦 G 的抢占标志位被设为 true，那么待这个 G 下一次调用函数或方法时，runtime 便可以将 G 抢占，并移出运行状态，放入 P 的 local runq 中，等待下一次被调度。」
是怎么由代码分析得到将被抢占调度的 G「放入 P 的 local runq 中，等待下一次被调度」。

另：https://wudaijun.com/2018/01/go-scheduler/ 一文认为， go sched 把被抢占调度的 G 放入了 global runq 中。

作者：Enzo

Enzo — Wed, 10 Jul 2019 08:23:11 +0000

详细，透彻，学习了

作者：Mark

Mark — Thu, 20 Jun 2019 11:25:29 +0000

好文章，感谢分享

作者：bigwhite

bigwhite — Thu, 28 Feb 2019 12:30:59 +0000

M对应线程。线程的创建和销毁的代价远高于goroutine。因此一旦thread创建，runtime不会轻易销毁它。后续没需要M时，会首先从idle thread中挑选一个。如果idle threads pool中没有idle thread,则会创建一个新的thread。如果非要求甚解（m何时被销毁），还是挖源码吧:)。

作者：yun-mu

yun-mu — Wed, 27 Feb 2019 02:55:50 +0000

请问M什么时候销毁呢，我只看到M被创建和sleep，M的生命周期是什么？

作者：bigwhite

bigwhite — Mon, 25 Dec 2017 12:00:50 +0000

嗯，是block on syscall的状态。这里本想表达的也是这个意思。只是用了一个广义的“sleep”，可能不是那么恰当:(。