Erlang程序中race condition的发现讲座小记

因为是针对Erlang所以这里race condition就是指message passing的部分，因为Erlang里边没有共享内存，而相互之间只能通过发送消息，而通常来说认为，发送消息很快速，基本这边一发，另外一边就收到了，有点类似于传统thread共享内存时候的感觉，就是很短暂，普通的时候不容易发现错误，所以有了这么个PULSE的项目。

例子就是，就是维持一个counter有read，write的方法，同时，如果有一个incr的函数，作为atomic的，就没得讲了，但是如果incr也只是简单的通过read再update之后write回去的方法，就不见得是atomic的了，这里也是故意这么加入的，达到故意有一个race condition的效果，然后演示如何用PULSE来发现这种bug的过程。

使用的是eqc_par_statem不过现在基本已经合并到了eqc_statem当中了。有几点就是声明并行比较难，但是串行相对容易，在后来euc的讲座中，John提到了，总有一种串行出来的方法来达到验证系统状态。然后启动几个clients随机的顺序执行，然后来测试。

对于incr的解释，因为是用read和write组合实现的，所以有interleaving的过程，运行你一会儿，运行我一会儿的。quickcheck的话，最开始能够发现这种错误，由于很多的大量混在一起，但是很难重现。

所以引出了PULSE的项目，PULSE主要是替代了Erlang自己本身的schedular，使用一种random的scheduling并且preemtpy抢占更频繁，更容易发现错误，而且可以log整个的过程，所以可以过后分析，重复。可以参考另外thomas的论文，就是trace一个Erlang程序的那个文章。

用了PULSE能产生一个图形，表示了两个进程的，但是怎么去解读这个图，还需要学习，首先需要明白怎么产生这个图。

PULSE的设计，不用解释器，只是普通的Erlang代码，不用hook到Erlang的vm当中，只是instrumented code加上额外的一个scheduler process，这样就可以控制processes之间交互发送消息的过程。有点类似于cover的道理感觉，可以看看cover是怎么工作的，感觉应该就是这个道理，就是每一次的调用，都被一个额外的人监控到了。对于PULSE的例子，就是schedular可能会停下来某一个进程，通过让该进程给schedular发消息，等回复，就是John在euc讲的i'm ready to run的道理。当实际的进程之间发送消息的时候，实际上是发送到了shceduler当中，作为一个中转，这样就可以达到故意延迟的目的，才能暴露这种message passing过程当中的race condition基本道理就跟我自己玩的时候加入点延迟道理差不多，不过我的延迟只能针对一个一个的语句，而这里message passing等于是在我看来的原子操作上再一次打碎，延迟。