标签：io strong for ar div cti 时间 sp on
“首先明确一点，Erlang的process的调度是抢占式的，而非couroutine的协作式的。其次，Erlang早期版本是只有一个调度器，运行在一个线程上，随着erts的发展，现在erlang的调度器已经支持smp，每个cpu关联一个调度器，并且可以明确指定哪个调度器绑定到哪个cpu上。第三，Erlang的调度也是采用优先队列+时间片轮询的方式，每个调度器关联一个ErtsRunQueue，ErtsRunQueue内部又分为三个ErtsRunPrioQueue队列，分别对应high,max和normal,low的优先级，其中normal和low共用一个队列；在Erlang中时间片是以reduction为单位，你可以将reduction理解成一次函数调用，每个被调度的process能执行的reduction次数是有限的。调度器每次都是从max队列开始寻找等待调度的process并执行，当前调度的队列如果为空或者执行的reductions超过限制，那么就降低优先级，调度下一个队列。”---迄今为止找到最好的解释reduction了。但是这里还是需要日后去证实的！包括每个优先级额定reduction是多少？因为目前测试每次调用reduction都在不断的增加，这意味着系统存在一个“标准”来定义上次进程执行的reduction和本次调用时reduction的差值。一旦这个差值超过额定reduction，该进程就会被挂起，被调度。
--------------------追加:为什么第一时间没有去看官方文档 ~ >.< ~ -----------------------
官方文档：
erlang:bump_reductions(Reductions) -> true
Types:
This implementation-dependent function increments the reduction counter for the calling process. In the Beam emulator, thereduction counter is normally incremented by one for each function and BIF call, and a context switch is forced when the counter reaches the maximum number of reductions for a process (2000 reductions in R12B).
Scheduling is preemptive. Regardless of priority, a process is preempted when it has consumed more than a certain amount of reductions since the last time it was selected for execution.
意思就是说每次函数调用或者bif调用都会增加reduction的值。在R12B中额定值是2000。(当前reduction) - (本次进程获得资源一开始的reduction) > 2000 不论优先级强行调度！
ps：只有在程序中才能存在绝对的公平~~~
标签：io strong for ar div cti 时间 sp on
原文地址：http://www.cnblogs.com/rsblog/p/3934570.html
