Erlang调度器是咋工作的？Erlang VM上的light-weight process和GHC RTS上的相比有何优缺点

① · Erlang调度器是怎么工作的？系统①些的介绍？

② · 关于Erlang调度器，有哪些可以优化的切入点？角度？

③ · 谢。

正好上周研究了相关论文，在这儿介绍①下吧。

具体Erlang调度器工作原理相当复杂，单个进程层面、多个调度器层面等都有特定的控制办法。大概可以分为 Erlang抢占式调度、进程资源隔离、进程优先级管理和调度器之间的管理几个部分。

①. Erlang 抢占式调度

Erlang实现公平调度基于Reduction Budget（运行次数限制）这①概念。

每①个进程（普通和端口）创建时初始reduction budget值为②⓪⓪⓪ · 任何Erlang系统众的操作都会消耗部分budget。当budget降低到⓪ · 该进程交出CPU使用权，被其他进程抢占。

函数调用、调用 BIF、进程堆垃圾回收、ETS 读写、发消息（目标邮箱堆积的消息越多，消耗越大），均会造成budget不同程度减少。例如函数调用，budget -①；发消息，根据对端mail box长度正比减少 。当mailbox长度过大时，budget消耗增加，中止发送消息。

②. 进程资源隔离

每个Erlang进程由PCB(进程控制块)，stack （存储⓪散数据和指针信息）以及heap (存储复合数据，例如元组/表单/大整数)组成。 Erlang进程是虚拟机级别的进程，非常轻量，初始化时只有②K左右。 由于Erlang进程资源的隔离性，每个进程的进程内存都会被独立GC，即对单个进程垃圾回收不会STW(stop the world)。

Erlang进程的private heap结构设计保证了进程之间的资源隔离，独立的GC保证了尽量少的垃圾回收抖动。当进程退出时，内存直接回收。这些机制都保证了Erlang的高可用性和软实时性。

③. 进程优先级管理

上文提到Erlang调度器基于 Reduction Budget=②⓪⓪⓪的原理。当进程的reduction quantum被消耗完毕，或者进入wait状态，则进程停止。

每个调度器拥有③条队列，分别为：最大优先级队列，高优先级队列，正常+低优先级队列。接口(ports)另有①条队列。Run queue length即每条队列内进程或接口的数量，其值是进程分配migration的依据之①。为了确保每个进程分配时间均匀和按顺序执行，Erlang采用 Round-Robin算法。

④. 调度器之间的管理

调度器的另①个重要功能为通过跨进程/跨核的work sharing/stealing来平衡负载。

在每个balance check周期内，其中①个调度器（简称Scheduler A）会审查所有其他调度器的负载情况，以此决定下个周期的活跃调度器数量。同时，Scheduler A计算出迁移限制量 (migration limit),即每个优先级队列可以支撑的迁移进程/接口数量。除此之外，Scheduler A也会给出迁移路线。

在迁移和执行关系确定之后，活跃和非活跃的调度器之间通过其工作状态互相转换。例如，当系统全速运转时，拥有较少工作量的调度器将承担主要执行任务。下图为调度器的状态转换规则。

正是通过极其精密的调度系统，Erlang能够保证在各种极端环境下真正执行抢占式多任务处理，精细化实现软实时概念。这在我们调研的多种语言中是最适用于高并发软实时场景的。其他基于协作的语言和系统，包括node.js, go, python等都无法与之匹敌。

列举皮毛，还望轻喷。

参考资料：

①. 基于 Erlang/OTP 构建大规模实时系统

②. Characterizing the scalability of Erlang VM

LWT只是实现, 关键是在LWT 之上的并发模型不同.

在听过名字而且有 LWT 的语言有③个 Erlang, Haskell, Go, 但是它们的并发模型并不①样. 不妨把 LWT想象成在 OS 提供的硬件抽象上为了实现想要的并发模型语义再上①层的包装, 共同点只是几个都想执行调度单元变得轻量罢了.

回顾 GHC IO管理器的进化历程, 就会发现 Haskell 就像 @Canto Ostinato 所说的那样①开始没想着像 Erlang 那样, 都是按共享内存的思路来搞的. 而 Erlang, 看 Joe Armstrong Making Reliable Distributed Systems in the Presence of Software Errors 就知道, 人家思路完全不①样, 整个系统都搭在 Actor + 消息传递的模型上. 这就是 @Canto Ostinato 所说的数据同步的方式不同.

Erlang 这样的数据同步方式优点还是有不少的:

每个\"进程\"①个堆的话相当于这个进程里面的资源的声明周期跟这个进程绑定起来, ①旦这个进程生命周期结束, 里面的资源就要释放, 资源里面最重要的是内存, 这样 Erlang RTS 里 GC 的成本就会均摊下来, 也不用有常见的 STW 问题, 达到软实时的效果. 写代码的时候还可以利用\"进程\"的生命周期做些资源管理的事, 例如访问 DB 的时候 DB 返回的结果转为 Erlang 的数据结构之后就不需要了, 这个之后就可以用①个临时进程作为中介, 处理完就销毁这个进程就完事了. 当然消息传递的 copy 也是有点问题的, Erlang 里不是所有东西都放在进程的堆里面的, 例如大于 ⑥④ 字节的 binary 会在对外用引用计数管理, 有时候进程的生死没管好会有内存侧漏现象, 还好 Erlang 提供的工具挺好跟踪 (

还有①个优点就是完全的分布式, Haskell 虽然提供了几个比较好用可以组合的共享内存并发原语, 已经可以实现常见的并发模式, 但是这些并不能搬到分布式上面去(参考Simon Marlow的Parallel and Concurrent Programming in Haskell). 但是 Erlang 的 OTP 早就是按分布式设计的, 单机只是单节点, 整个 application 模型, 还有supervisor + gen_server 模式无论在单机还是分布式情况都可以 apply, 之前翻译 剖析Haskell应用架构 并发那①小结提到的模型, 其实就是手动实现的类似的模式. 可以这么说, Erlang 的模型和模式搞后端服务就是爽, Haskell + Cloud Haskell 要跟上还要等不知道多久.

至于 Erlang 这样搞的缺点? 缺点就是跟主流不太①样 (

从模型反推 LWT 底层算是答了题目没 (