Erlang 进程被抢占的条件——一个进程长时霸占调度器的极端示例

最近研究 binary 的实现和各种操作对应的 beam 虚拟机汇编指令，发现有一些指令序列是不可重入的，比如说有的指令构造一个上下文（也就是某种全局状态），然后下一条指令会对这个上下文做操作（具体的场景示例参见这篇博文）。而上下文是调度器内部私有的全局变量。而我们一直在说，Erlang 调度器是抢占式调度器，进程耗光了 reduction 配额之后就会被抢占，那么调度器是怎么保证不可重入的指令序列不会被破坏呢？

关键在于，Erlang 调度器的抢占只会发生在一些特定的点上，像上面的指令序列之间是不会发生抢占的。

在 beam_emu.c 文件中，上下文切换（抢占必然要上下文切换）是通过 Dispatch()、Dispatchx() 和 Dispatchfun() 三个宏完成的，暂不用纠缠这些宏的区别和细节。比如说第一个宏 Dispatch()：

#define DispatchMacro()                
  do {                        
     BeamInstr* dis_next;                
     dis_next = (BeamInstr *) *I;            
     CHECK_ARGS(I);                
     if (FCALLS > 0 || FCALLS > neg_o_reds) {    
        FCALLS--;                
        Goto(dis_next);                
     } else {                    
    goto context_switch;            
     }                        
 } while (0)

#  define Dispatch() DispatchMacro()

在 if 语句的 else 分句部分，可以看出 FCALLS 不够了就要 goto 到 context_switch，FCALLS 表示剩余的 reduction 数，context_switch 那里就要调用调度器切换进程了。

在这个文件中搜索一下，差不多可以看出哪些地方调用了这些宏，比如说下面几条和函数调用相关的指令：

基本上都是和函数调用相关的指令，还有 call_bif，apply 之类的。这说明一个关键点：那就是 Erlang 虚拟机不会在任意指令之间或指令中抢占进程，而是在特定的点会发生抢占。

好消息是，Erlang 的设计使得 Erlang 会经常到达这些特定的点。比如说，Erlang 中没有循环结构，循环是通过递归调用自己实现的，那么这就可以保证超长的“循环”可以被抢占，而这在其他非函数式语言中可能就不好实现了。

再举一个例子，比如说前一篇博文提到的  binary comprehension，代码如下：

bc(Input) -> 
    << <<0, 1, 2, Bin:8/binary>> || <<Bin:8/binary>> <= Input >>.

我一开始担心，这一行中间也没有任何调用，要是 Input 很大该怎么办呢？会不会导致霸占调度器时间过长？不过看了编译器生成的汇编码就不用担心了：

可以看到，在第 12 步，有一条 call_only 指令。尽管第 8 到第 11 步中间的那些指令的序列在 Erlang 虚拟机看来是“原子”的，不会被打断，但是第 12 步就有可能发生抢占。

但是要特别注意的是，我们不能就此完全放心了，中间的这些指令可都是不消耗 reduction 的啊，这些指令还涉及到复制操作，所以如果复制的时间很长，那么这个函数霸占调度器的时间也会更长了。

下面举一个很变态的例子：

binary_append_longrun(Bin0) ->
    Bin1 = <<Bin0/binary, Bin0/binary, Bin0/binary, Bin0/binary>>,
    Reds1 = erlang:process_info(self(), reductions),
    Bin2 = <<Bin1/binary, Bin1/binary, Bin1/binary, Bin1/binary>>,
    Reds2 = erlang:process_info(self(), reductions),
    Bin3 = <<Bin2/binary, Bin2/binary, Bin2/binary, Bin2/binary>>,
    Reds3 = erlang:process_info(self(), reductions),
    Bin4 = <<Bin3/binary, Bin3/binary, Bin3/binary, Bin3/binary>>,
    Reds4 = erlang:process_info(self(), reductions),
    Bin5 = <<Bin4/binary, Bin4/binary, Bin4/binary, Bin4/binary>>,
    Reds5 = erlang:process_info(self(), reductions),
    Bin6 = <<Bin5/binary, Bin5/binary, Bin5/binary, Bin5/binary>>,
    Reds6 = erlang:process_info(self(), reductions),
    Bin7 = <<Bin6/binary, Bin6/binary, Bin6/binary, Bin6/binary>>,
    Reds7 = erlang:process_info(self(), reductions),
    Bin8 = <<Bin7/binary, Bin7/binary, Bin7/binary, Bin7/binary>>,
    Reds8 = erlang:process_info(self(), reductions),
    Bin9 = <<Bin8/binary, Bin8/binary, Bin8/binary, Bin8/binary>>,
    Reds9 = erlang:process_info(self(), reductions),
    Bin10 = <<Bin9/binary, Bin9/binary, Bin9/binary, Bin9/binary>>,
    Reds10 = erlang:process_info(self(), reductions),
    Bin11 = <<Bin10/binary, Bin10/binary, Bin10/binary, Bin10/binary>>,
    Reds11 = erlang:process_info(self(), reductions),
    Bin12 = <<Bin11/binary, Bin11/binary, Bin11/binary, Bin11/binary>>,
    Reds12 = erlang:process_info(self(), reductions),
    Bin13 = <<Bin12/binary, Bin12/binary, Bin12/binary, Bin12/binary>>,
    Reds13 = erlang:process_info(self(), reductions),
    Bin14 = <<Bin13/binary, Bin13/binary, Bin13/binary, Bin13/binary>>,
    Reds14 = erlang:process_info(self(), reductions),
    Bin15 = <<Bin14/binary, Bin14/binary, Bin14/binary, Bin14/binary>>,
    Reds15 = erlang:process_info(self(), reductions),
    Bin16 = <<Bin15/binary, Bin15/binary, Bin15/binary, Bin15/binary>>,
    Reds16 = erlang:process_info(self(), reductions),
    Res = {Reds1, Reds2, Reds3, Reds4, Reds5, Reds6, Reds7, Reds8, Reds9, Reds10, Reds11, Reds12, Reds13, Reds14, Reds15, Reds16, byte_size(Bin16)},
    Res.

这个变态的函数接受一个 binary Bin0 作为参数。然后 Bin1 变成 4 个 Bin0那么大，Bin2 变成 4 个 Bin1 那么大，以此类推，最后 Bin16 就有 (4^{16}) 个 Bin0 那么大了。Bin0 是 1 字节的话，Bin16 就有 4G 字节那么大。Bin15 有 1G 字节那么大。在第 32 行，即使有预分配内存的优化，这一行还得复制 3 次 1G 字节的数据。显然这是非常费时的操作。

为了观察 reduction 的变化，在中间安插了一些 bif 调用获得当前进程的 reduction 值。我们看一下运行结果：

461> spawn(fun() -> Res = bin_test:binary_append_longrun(<<0>>), io:format("~p~n", [Res]) end). 
{{reductions,63},
 {reductions,65},
 {reductions,67},
 {reductions,69},
 {reductions,71},
 {reductions,73},
 {reductions,75},
 {reductions,77},
 {reductions,79},
 {reductions,81},
 {reductions,83},
 {reductions,85},
 {reductions,87},
 {reductions,89},
 {reductions,91},
 {reductions,93},
 4294967296}
<0.175.1>

在终端 spawn 了一个进程，让新进程去跑这个函数，跑完之后打印最后的结果。结果按下回车之后，shell 失去响应。等了好一阵子之后，才把结果打印出来。从结果可以看出，这个新创建的进程跑到结束也才用了几十个 reduction。而且，整个调度器都失去了响应。怎么说呢？如果调度器有响应的话，新建进程的 pid，也就是 spawn 的返回值，应该很快在 shell 中打印出来，但是直到新进程执行完了才打印出来。而且如果之前打开了 observer 或 etop 之类的工具，GUI 也是在这个进程执行期间没有反应的。可以说，这个进程在跑的时候，Erlang 就没法“实时”了，连“软实时”都没了。

当然，我们在实际写程序的时候不太可能会写出这样变态的极端情况。可是万一呢。。。有些情况下，例如追加特别大的 binary 的情况，而且需要反复执行多次的时候，这个进程扣的 reduction 并不多，所以这种进程可能会破坏系统的响应能力。