使用软件事务内存的任何真实体验？

似乎最近对STM(软件事务内存)框架和语言扩展的兴趣日益增加. 特别是Clojure有一个很好的实现,它使用MVCC(多版本并发控制)而不是滚动提交日志.GHC Haskell也有一个非常优雅的STM monad,它也允许交易组成.最后,为了给自己的号角做一点点,我最近为Scala实现了一个静态强制引用限制的STM框架.

所有这些都是有趣的实验,但它们似乎仅限于那个领域(实验).所以我的问题是:你们有没有在现实世界中看到过或使用过STM？如果是这样,为什么？它带来了什么样的好处？性能怎么样？(关于这一点似乎存在大量相互矛盾的信息)你会再次使用STM还是更喜欢使用像actor这样的其他并发抽象？

我参与了Haskell中BitTorrent客户端的爱好者开发(名为conjure).它使用STM来协调不同的线程(每个对等1个用于存储管理,1个用于整体管理).

好处:减少锁,可读代码.

速度不是问题,至少不是由于STM的使用.

希望这可以帮助

文章"软件交易记忆:为什么它只是一个研究玩具？" 没有看到Haskell实现,这是一个非常大的遗漏.正如文章所指出的,STM的问题在于,实现必须在使所有变量访问事务处理之间进行选择,除非编译器能够证明它们是安全的(这会导致性能下降)或者让程序员指出哪些是事务性的(这会导致简单性和可靠性).然而,Haskell实现使用Haskell的纯度来避免使大多数变量使用事务性的需要,而类型系统提供简单的模型以及事务变异操作的有效实施.

我们常常将它用于Galois(在Haskell中)的高并发应用程序.它可以工作,它在Haskell世界中广泛使用,并且它没有死锁(当然你可以有太多的争用).如果我们的设计正确,我们有时会重写使用MVars的东西 - 因为它们更快.

只是使用它.这没什么大不了的.就我而言,Haskell中的STM是"已经解决"的.没有进一步的工作要做.所以我们使用它.

我们,factis research GmbH,正在使用Haskell STM和GHC进行生产.我们的服务器从临床"数据服务器"接收关于新的和修改的"对象"的消息流,它动态地转换这个事件流(通过生成新对象,修改对象,聚合事物等)并计算这些新事件中的哪一个对象应与已连接的iPad同步.它还接收来自iPad的表单输入,这些输入被处理,与"主流"合并并且还与其他iPad同步.我们将STM用于需要在线程之间共享的所有通道和可变数据结构.Haskell中的线程非常轻量级,所以我们可以在不影响性能的情况下使用很多线程(目前每个iPad连接有5个).构建大型应用程序始终是一项挑战,需要学习许多课程,但我们从未遇到任何STM问题.它总是像你天真的期待一样工作.我们不得不做一些严肃的性能调整,但STM从来都不是问题.(80%的时间我们都在尝试减少短期分配和总内存使用量.)

STM是Haskell和GHC运行时真正发挥作用的一个领域.这不仅仅是一个实验,也不仅限于玩具程序.

我们在Scala中构建了一个不同的clincal系统组件,到目前为止一直在使用Actors,但我们确实缺少STM.如果有人体验过在生产中使用Scala STM实现之一的感受,我很乐意听取您的意见.:-)