事务内存需要什么才能变得可行？

Question

我一直在研究事务性内存及其对系统编程（数据库、操作系统、服务器等）的可行性。我自己使用事务的经验，以及看到很少有社区在实际代码中使用事务，提出了一个问题：什么会说服你，一个编写生产代码的开发人员，在你的工作中使用事务内存？

会被普遍采用吗？高速？提高可靠性？多少？

---

对于那些还没有见过它们的人，内存事务就像数据库事务：操作（显然）并行进行，如果两个事务之间存在冲突（例如，它们都写入相同的值），那么一个或两个的事务将被回滚并重新启动。

事务性内存有几个好处：

1. 可靠性完全摆脱死锁（例如错误顺序锁定）。
2. 性能 锁争用较少时速度更快。
3. 可编程性 精细的并发控制，无需管理许多同步对象。

即使假设 TM 是正确、完整和快速的实现，与锁相比，这个原语也存在已知的缺点。

1. 由于事务可能会执行多次，因此除了通过经验实验之外，更难以预测性能。

   我们可以重现性能错误吗？

2. 在正确的实现之间存在一些不同的政策决定，例如在另一个事务中结束的事务会发生什么？我们是现在提交，还是等待？

   我们能否充分理解代码的局部影响？

3. 为了在回滚的事务中支持不可撤销的行为（例如发送“发射导弹”命令），运行时变得更加复杂。

   我们能否充分理解代码的全局影响？

最后，由于软件实现可能首先被使用（C、C++、Haskell、Clojure 和 Scala 等已经有实现），实际上存在性能问题。在适度的争用下，软件事务会带来性能损失。

您的绩效预算是多少？什么时候收益大于潜在成本？

Answer 1

我已经对TBoost STM 进行了一些试验，它似乎是可用的，尽管我还不习惯在生产产品中使用它。不过，所需的思维转变很重要，所以我怀疑它会流行起来，除非它在实际应用中显示出令人信服的好处。

我一直听说，随着 CPU 的内核开始翻倍，就像它们过去的频率翻倍一样，大规模并行计算将成为未来。到目前为止，4 核和 8 核台式机并没有真正显示出对一般工作负载有用。我认为我们有一个先有鸡还是先有蛋的问题：采用并行机器正在等待能够充分利用优势的软件，而高度并行软件的主流开发正在等待高度并行硬件的普及。

我认为也许需要一个开源软件项目来采用 STM 模型来实现像 Web 服务器这样的东西。像这样一个成功的项目将是一个很好的模型，并且可能通过证明 STM 已为现实世界做好准备，从而激发整个软件行业的兴趣。

Answer 2

几件事：

1) 软件事务内存 (STM) 系统必须稳健、可靠且经过测试，才能真正发挥作用。

2) 无竞争的 STM 事务的性能开销应该与具有无竞争锁的相同例程相当。

3) STM 系统在多个事务处于挂起状态时的性能必须比在竞争资源上使用锁要好得多。

Answer 3

我认为 A STM 系统必须为用户采用提供一些标准：

简单性：使用事务理论上比使用锁更简单，但实际情况并非如此就没有理由使用它。

性能：用户可以接受性能比使用锁要慢一点，但不会太慢。

与非事务性世界的交互： 仅在仅事务性世界上工作的 STM 系统对于在需要使用遗留系统或有其他限制的项目中工作的人来说是无法成功的，这可以使用其他范例更好地解决。

正确性：用户需要确信他/她使用的系统在其基础和实施上都是正确的。目前的STM系统大部分还没有处于产品阶段，所以人们可能会受到版本不稳定的影响。

调试工具：调试器工具必须适应这种新的范例（至少当 STM 系统被纳入该语言时），因为当相同的代码被多次执行时，调试可能会更加复杂有冲突的时候。