我一直在处理事务内存及其系统编程（数据库，操作系统，服务器等）的可行性。我自己使用交易的经验，以及看到有多少社区在实际代码中使用交易，提出了一个问题：什么会说服你，一个编写生产代码的开发人员，在你的工作中使用交易记忆？
是否会被普遍采用？高速？提高可靠性？多少钱？
对于那些没有看过它们的人来说，内存事务就像数据库事务一样：操作并行进行（显然），如果两个事务之间存在冲突（例如，它们都写入相同的值），那么一个或两个这些交易将被回滚并重新启动。
交易记忆有一些好处：
然而，即使假设TM 的正确，完整和快速实现，与锁相比，这个原语也有已知的缺点。
由于交易可能会多次执行，除了经验实验外，预测绩效更加困难。
我们能否重现性能错误？
有些政策决定在正确的实施方式之间有所不同，例如：在另一个交易中结束的交易会发生什么？我们现在承诺，还是等我们？
我们能充分了解代码的本地效果吗？
为了支持不可撤销的行为（例如，在回滚的事务中发送“fire missiles”命令），运行时变得更加复杂。
我们是否可以充分了解代码的全局影响？
最后，由于软件实现可能是第一个使用的（已经有C，C ++，Haskell，Clojure和Scala等实现），实际上存在性能问题。在适度争用的情况下，软件交易会受到性能影响。
您的绩效预算是多少？这些好处在多大程度上超过了潜在的成本？
答案 0 :(得分：3)
我已经完成了TBoost STM的一些实验，它似乎可以使用，但我还不习惯在生产产品中使用它。所需的思维转变是重要的，所以我怀疑它会流行，除非它在实际应用中显示出令人信服的好处。
我一直听说未来是在大规模并行计算中，因为CPU在内核中开始加倍，就像以前的频率加倍一样。到目前为止，4核和8核桌面并没有真正显示出对一般工作负载有用。我认为我们有一个鸡与蛋的问题：并行机器的采用正在等待能够充分利用的软件，而高度并行软件的主流开发正在等待高度并行的硬件无处不在。
我想也许所需要的是一个开源软件项目，为Web服务器之类的东西采用STM模型。像这样的成功项目将是一个很好的模型，可以通过证明STM为现实世界做好准备来帮助启动整个软件行业的兴趣。
答案 1 :(得分：3)
有几件事：
1）软件事务内存（STM）系统必须健壮，可靠并经过测试才能实际运行。
2）无争议的STM事务的性能开销应与具有无争议锁定的相同例程相当。
3）当多个交易处于待决状态时，STM系统必须表现得更好，而对有争议的资源使用锁定。
答案 2 :(得分：0)
我认为STM系统必须为用户采用提供一些标准：
简单：理论上使用事务比使用锁更简单，但在实践中并不是没有理由使用它。
演出：用户可以接受演奏比使用锁慢一点，但速度不会太慢。
与非交易世界的互动：仅适用于仅限交易世界的STM系统无法在需要使用旧系统的项目中工作的人员成功，或者具有其他约束，这可以使用其他范例更好地解决。
正确性：用户需要确信他/她正在使用的系统在其基础和实施方面是正确的。目前大多数STM系统还没有处于产品阶段，因此人们可能暂时遭遇不稳定版本。
调试工具：调试器工具必须适应这种新范例（至少在STM系统包含在语言中时），因为当执行相同的代码时，调试可能会更复杂如果有冲突的话。