GPars小试

2019独角兽企业重金招聘Python工程师标准>>>

最近，Transentia的Blog上发布了一篇“GPars小试”的文章，作者通过实现“以讹传讹（Chinese Whispers）”的游戏，展示了GPars中Actor和Dataflow的使用。

这个游戏的规则很简单：

……有一个产生消息的源线程，它通过一系列的中介把消息传给目标线程，目标线程简单地把消息再沿着消息链传回来。在传往目的地的途中，中介向下一个传递消息时，可能改动也可能不改动消息，因此最终沿原路返回的消息可能会以预想不到的方式被修改了。

本站已经发布了GPars的系列文章，它的概念和使用都会在这个系列中介绍，在此，我就不再重复。这里，我们主要关注作者对于GPars的一些见解。

作者首先采用Actor模型实现了这个游戏，关于这段代码，请参见原文。对于该模型，作者有一段非常有趣的话：

如果你熟悉Web开发，你可以把Actor认为是Servlet……

这种比喻倒也确实形象。对于GPars的Actor，作者的基本看法是：

简单、高效、易写、易读。你还想怎么样？

GPars Actors并不完美（它们缺少Scala库的一些更精巧的能力，如监视消息接收的模式匹配，可以查看入站消息队列的长度），但它们也不是太寒酸。

接着，作者又用Dataflow重新实现了一遍游戏。由于目前GPars这个系列尚未谈到Dataflow，在此简单的引用一下原文：

Dataflow并发提供了另一种并发模型，内建了安全性和健壮性。它把重点放在数据和它们在过程中的流向，而不是操作数据的实际过程。Dataflow算法把开发者从处理活锁、竞争条件的过程中解放了出来，使得死锁变得有确定性且100%可复现。如果你在测试中没有得到死锁，那么在产品环境中你同样也不会得到它。

同样，参考代码请访问原文。和前面的实现一样，你眼前的代码依旧简单得让人吃惊。

中介之间的每个双向链都被建模成带有‘up’和‘down’变量的Link。尽管GPars还提供了其他方式，但就这个例子，我选择使用普通的“Dataflow变量”，它是“一次写，多次读”的实体……

由于使用了Grape，Transentia这篇文章的例子都可以直接复制到Groovy Console中直接运行，当然首先请先确定你的Groovy版本是1.7.1。

请关注本站关于GPars的后续文章，关于本文中所提例子的详情请查看原文。

转载于:https://my.oschina.net/groovyland/blog/3031