4

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

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

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

事务性内存有几个好处：

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

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

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

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

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

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

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

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

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

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

4

3 回答 3

3

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

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

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

于 2009-11-19T17:41:11.377 回答
3

几件事：

1) 软件事务内存 (STM) 系统必须是健壮的、可靠的和经过测试的，这样它才能真正工作。

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

3) STM 系统在多个事务处于未决状态时的性能必须比对有争议的资源使用锁定要好得多。

于 2009-11-19T17:45:01.323 回答
0

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

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

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

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

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

调试工具：调试器工具必须适应这种新的范例（至少在语言中包含 STM 系统时），因为如果发生冲突，多次执行相同的代码时调试可能会更加复杂。

于 2010-05-18T12:55:24.397 回答