协作/非协作式抢占

Go 最近有一个比较有意思的 proposal,提出要将协作式的抢占调度修改为非协作式的抢占调度,并使 Go 的每一条指令理论上都可以被抢占。起因是因为之前有类似这样的问题。当然,社区里遇到问题的人很多,如果你感兴趣,还可以看看这些 github 上的 issue:#543, #12553, #13546, #14561, #15442, #17174, #20793, #21053。

之前的协作式抢占是怎么一回事呢,我翻译的这篇 里其实已经有提及,该文中提到的函数中的 prologue 和 epilogue 即是可以执行调度的一个典型时机(但不是全部,此外还包括有 syscall,channel 操作时等调度点)。可以调度,意味着在这个节点上可以抢占 goroutine,将其挂起,然后就可以进行 GC 了,调度点可以认为是 GC 的 safepoint。上述例子之所以会 hang 死,就是因为正在执行死循环的 g 可能永远都到不了 safepoint,所以调度器也拿它没办法。只能一直等待下去。这样用户侧看来的表现就可能是整个进程直接 hang 死了。

在提出修改调度之前,Go 的开发组还尝试了其它的一些方案,比如想办法在 for 循环的 backedge 上插入调度指令,可以参见这里。这个改动影响了一些数学函数的性能,比如 geomean 几何平均函数,性能下降了 7.8 %。想想的话也是必然的结果,毕竟你在循环里插入了额外的检查指令。

看计划,这个变动会在 1.12 上完全实现。对于用户来讲,由于这些修改没有 API 变动,所以并没有什么可感知的变化。唯一的变化大概是就算有死循环的 goroutine,也不会在 GC 的时候卡死了。

协作/非协作式抢占
Share this

家境贫寒,整理不易,客官如果觉得不错欢迎打赏!