scala 任何使用软件事务内存的真实世界经验？

Any Real-World Experience Using Software Transactional Memory?

提问by Daniel Spiewak

It seems that there has been a recent rising interest in STM (software transactional memory) frameworks and language extensions. Clojurein particular has an excellent implementation which uses MVCC (multi-version concurrency control)rather than a rolling commit log. GHC Haskell also has an extremely elegant STM monadwhich also allows transaction composition. Finally, so as to toot my own horn just a bit, I've recently implemented an STM framework for Scalawhich statically enforces reference restrictions.

似乎最近人们对 STM（软件事务内存）框架和语言扩展的兴趣日益浓厚。 特别是Clojure有一个出色的实现，它使用MVCC（多版本并发控制）而不是滚动提交日志。GHC Haskell 也有一个非常优雅的 STM monad，它也允许事务组合。最后，为了稍微吹嘘一下我自己的号角，我最近为 Scala实现了一个STM 框架，它静态地强制执行引用限制。

All of these are interesting experiments, but they seem to be confined to that sphere alone (experimentation). So my question is: have any of you seen or used STM in the real world? If so, why? What sort of benefits did it bring? What about performance? (there seems to be a great deal of conflicting information on this point) Would you use STM again or would you prefer to use some other concurrency abstraction like actors?

所有这些都是有趣的实验，但它们似乎仅限于那个领域（实验）。所以我的问题是：你们有没有人在现实世界中见过或使用过 STM？如果是这样，为什么？它带来了什么样的好处？性能呢？（在这一点上似乎有很多相互矛盾的信息）你会再次使用 STM 还是更喜欢使用其他一些并发抽象，比如 actor？

采纳答案by ADEpt

I participated in the hobbyist development of the BitTorrent client in Haskell (named conjure). It uses STM quite heavily to coordinate different threads (1 per peer + 1 for storage management + 1 for overall management).

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

Benefits: less locks, readable code.

好处：更少的锁，可读的代码。

Speed was not an issue, at least not due to STM usage.

速度不是问题，至少不是因为使用 STM。

Hope this helps

希望这可以帮助

回答by Paul Johnson

The article "Software Transactional Memory: Why is it Only a Research Toy?" (Ca?lin Ca?caval et al., Communications of the ACM, Nov. 2008), fails to look at the Haskell implementation, which is a really big omission. The problem for STM, as the article points out, is that implementations must chose between either making all variable accesses transactional unless the compiler can prove them safe (which kills performance) or letting the programmer indicate which ones are to be transactional (which kills simplicity and reliability). However the Haskell implementation uses the purity of Haskell to avoid the need to make most variable uses transactional, while the type system provides a simple model together with effective enforcement for the transactional mutation operations. Thus a Haskell program can use STM for those variables that are truly shared between threads whilst guaranteeing that non-transactional memory use is kept safe.

文章“软件事务内存：为什么它只是一个研究玩具？” （Ca?lin Ca?caval 等人，ACM 通讯，2008 年 11 月）, 没有看到 Haskell 的实现，这是一个非常大的遗漏。正如文章所指出的，STM 的问题是，实现必须在使所有变量访问事务性除非编译器可以证明它们是安全的（这会降低性能）或让程序员指出哪些是事务性的（这会扼杀简单性）之间做出选择和可靠性）。然而，Haskell 实现使用 Haskell 的纯度来避免需要使大多数变量使用事务性，而类型系统提供了一个简单的模型以及对事务性变异操作的有效执行。因此，Haskell 程序可以将 STM 用于那些真正在线程之间共享的变量，同时保证非事务性内存使用的安全。

回答by Don Stewart

We use it pretty routinely for high concurrency apps at Galois (in Haskell). It works, its used widely in the Haskell world, and it doesn't deadlock (though of course you can have too much contention). Sometimes we rewrite things to use MVars, if we've got the design right -- as they're faster.

我们在 Galois（在 Haskell 中）经常将它用于高并发应用程序。它有效，它在 Haskell 世界中被广泛使用，并且不会死锁（当然，您可能会有太多的争用）。有时我们会重写一些东西以使用 MVars，如果我们的设计正确的话——因为它们更快。

Just use it. It's no big deal. As far as I'm concerned, STM in Haskell is "solved". There's no further work to do. So we use it.

就用它。这没什么大不了的。就我而言，Haskell 中的 STM 已“解决”。没有进一步的工作要做。所以我们使用它。

回答by David Leuschner

We, factis research GmbH, are using Haskell STM with GHC in production. Our server receives a stream of messages about new and modified "objects" from a clincal "data server", it transforms this event stream on the fly (by generating new objects, modifying objects, aggregating things, etc) and calculates which of these new objects should be synchronized to connected iPads. It also receives form inputs from iPads which are processed, merged with the "main stream" and also synchronized to the other iPads. We're using STM for all channels and mutable data structures that need to be shared between threads. Threads are very lightweight in Haskell so we can have lots of them without impacting performance (at the moment 5 per iPad connection). Building a large application is always a challenge and there were many lessons to be learned but we never had any problems with STM. It always worked as you'd naively expect. We had to do some serious performance tuning but STM was never a problem. (80% of the time we were trying to reduce short-lived allocations and overall memory usage.)

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

STM is one area where Haskell and the GHC runtime really shines. It's not just an experiment and not for toy programs only.

STM 是 Haskell 和 GHC 运行时真正发挥作用的领域之一。这不仅仅是一项实验，也不仅仅适用于玩具程序。

We're building a different component of our clincal system in Scala and have been using Actors so far, but we're really missing STM. If anybody has experience of what it's like to use one of the Scala STM implementations in production I'd love to hear from you. :-)

我们正在 Scala 中构建我们的临床系统的不同组件，并且到目前为止一直在使用 Actors，但我们真的缺少 STM。如果有人对在生产中使用其中一种 Scala STM 实现有什么经验，我很乐意听取您的意见。:-)

回答by gtroxler

We have implemented our entire system(in-memory database and runtime) on top of our own STM implementation in C. Prior to this, we had some log and lock based mechanism to deal with concurrency, but this was a pain to maintain. We are very happy with STM since we can treat every operation the same way. Almost all locks could be removed. We use STM now for almost anything at any size, we even have a memory manager implement on top.

我们已经在我们自己的 STM 用 C 实现之上实现了我们的整个系统（内存数据库和运行时）。在此之前，我们有一些基于日志和锁的机制来处理并发，但这很难维护。我们对 STM 非常满意，因为我们可以以相同的方式对待每个操作。几乎所有的锁都可以移除。我们现在几乎将 STM 用于任何大小的任何东西，我们甚至在上面有一个内存管理器实现。

The performance is fine but to speed things up we now developed a custom operating systemin collaboration with ETH Zurich. The system natively supports transactional memory.

性能很好，但为了加快速度，我们现在与苏黎世联邦理工学院合作开发了一个自定义操作系统。系统本身支持事务内存。

But there are some challenges caused by STM as well. Especially with larger transactions and hotspots that cause unnecessary transaction conflicts. If for example two transactions put an item into a linked list, an unnecessary conflict will occur that could have been avoided using a lock free data structure.

但是STM也带来了一些挑战。尤其是较大的事务和热点会导致不必要的事务冲突。例如，如果两个事务将一个项目放入链表，就会发生不必要的冲突，而使用无锁​​数据结构可以避免这种冲突。

回答by Marc

I'm currently using Akka in some PGAS systems research. Akkais a Scala library for developing scalable concurrent systems using Actors, STM, and built-in fault tolerance capabilities modeled after Erlang's "Let It Fail/Crash/Crater/ROFL" philosophy. Akka's STM implementation is supposedly built around a Scala port of Clojure's STM implementation. An overview of Akka's STM module can be found here.

我目前在一些 PGAS 系统研究中使用 Akka。Akka是一个 Scala 库，用于使用 Actors、STM 和内置容错功能开发可扩展的并发系统，这些功能以 Erlang 的“Let It Fail/Crash/Crater/ROFL”哲学为模型。Akka 的 STM 实现据说是围绕 Clojure 的 STM 实现的 Scala 端口构建的。Akka 的 STM 模块概述可以在这里找到。