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

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

孙飞 Sunface

1697人浏览 · 2014-04-19 14:28:05

孙飞 Sunface · 2014-04-19 14:28:05 发布

转载自：http://www.cnblogs.com/zhengsyao/p/erlang_process_preemption_conditions.html

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

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

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

 1 #define DispatchMacro()                \
 2   do {                        \
 3      BeamInstr* dis_next;                \
 4      dis_next = (BeamInstr *) *I;            \
 5      CHECK_ARGS(I);                \
 6      if (FCALLS > 0 || FCALLS > neg_o_reds) {    \
 7         FCALLS--;                \
 8         Goto(dis_next);                \
 9      } else {                    \
10     goto context_switch;            \
11      }                        \
12  } while (0)
13 
14 #  define Dispatch() DispatchMacro()

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

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

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

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

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

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

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

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

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

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

 1 binary_append_longrun(Bin0) ->
 2     Bin1 = <<Bin0/binary, Bin0/binary, Bin0/binary, Bin0/binary>>,
 3     Reds1 = erlang:process_info(self(), reductions),
 4     Bin2 = <<Bin1/binary, Bin1/binary, Bin1/binary, Bin1/binary>>,
 5     Reds2 = erlang:process_info(self(), reductions),
 6     Bin3 = <<Bin2/binary, Bin2/binary, Bin2/binary, Bin2/binary>>,
 7     Reds3 = erlang:process_info(self(), reductions),
 8     Bin4 = <<Bin3/binary, Bin3/binary, Bin3/binary, Bin3/binary>>,
 9     Reds4 = erlang:process_info(self(), reductions),
10     Bin5 = <<Bin4/binary, Bin4/binary, Bin4/binary, Bin4/binary>>,
11     Reds5 = erlang:process_info(self(), reductions),
12     Bin6 = <<Bin5/binary, Bin5/binary, Bin5/binary, Bin5/binary>>,
13     Reds6 = erlang:process_info(self(), reductions),
14     Bin7 = <<Bin6/binary, Bin6/binary, Bin6/binary, Bin6/binary>>,
15     Reds7 = erlang:process_info(self(), reductions),
16     Bin8 = <<Bin7/binary, Bin7/binary, Bin7/binary, Bin7/binary>>,
17     Reds8 = erlang:process_info(self(), reductions),
18     Bin9 = <<Bin8/binary, Bin8/binary, Bin8/binary, Bin8/binary>>,
19     Reds9 = erlang:process_info(self(), reductions),
20     Bin10 = <<Bin9/binary, Bin9/binary, Bin9/binary, Bin9/binary>>,
21     Reds10 = erlang:process_info(self(), reductions),
22     Bin11 = <<Bin10/binary, Bin10/binary, Bin10/binary, Bin10/binary>>,
23     Reds11 = erlang:process_info(self(), reductions),
24     Bin12 = <<Bin11/binary, Bin11/binary, Bin11/binary, Bin11/binary>>,
25     Reds12 = erlang:process_info(self(), reductions),
26     Bin13 = <<Bin12/binary, Bin12/binary, Bin12/binary, Bin12/binary>>,
27     Reds13 = erlang:process_info(self(), reductions),
28     Bin14 = <<Bin13/binary, Bin13/binary, Bin13/binary, Bin13/binary>>,
29     Reds14 = erlang:process_info(self(), reductions),
30     Bin15 = <<Bin14/binary, Bin14/binary, Bin14/binary, Bin14/binary>>,
31     Reds15 = erlang:process_info(self(), reductions),
32     Bin16 = <<Bin15/binary, Bin15/binary, Bin15/binary, Bin15/binary>>,
33     Reds16 = erlang:process_info(self(), reductions),
34     Res = {Reds1, Reds2, Reds3, Reds4, Reds5, Reds6, Reds7, Reds8, Reds9, Reds10, Reds11, Reds12, Reds13, Reds14, Reds15, Reds16, byte_size(Bin16)},
35     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 并不多，所以这种进程可能会破坏系统的响应能力。