我一直在处理事务内存及其系统编程(数据库,操作系统,服务器等)的可行性.我自己使用交易的经验,以及看到有多少社区在实际代码中使用交易,提出了一个问题：什么会说服你,一个编写
它会被普遍采用吗？高速？提高可靠性？多少钱？
对于那些没有看到它们的人来说,内存事务就像数据库事务一样：操作(显然)并行进行,如果两个事务之间存在冲突(例如,它们都写入相同的值),那么一个或两个事务将回滚并重新启动.
事务性内存有一些好处：
>可靠性完全摆脱死锁(例如错误的订单锁定).
>性能锁定争用率低时速度更快.
>可编程性细粒度并发控制,无需管理多个同步对象.
然而,即使假设TM的正确,完整和快速实现,与锁相比,该基元也存在已知的缺点.
>由于交易可能会多次执行,除了经验实验之外,预测绩效更加困难.
我们能否重现性能错误？
>有些政策决定在正确的实施方案之间有所不同,例如：在另一个交易中结束的交易会发生什么？我们现在承诺,还是我们等？
我们能否充分了解代码的局部效应？
>为了支持不可撤销的行为(例如,在回滚的事务中发送“fire missiles”命令),运行时变得更加复杂.
我们能否充分了解代码的全局影响？
最后,由于软件实现可能是第一个使用的(已经有C,C,Haskell,Clojure和Scala中的实现,仅举几例),实际上存在性能问题.在适度争用的情况下,软件交易会受到性能影响.
您的绩效预算是多少？这些好处在多大程度上超过了潜在的成本？
我已经做了一些 TBoost STM的实验,它似乎是可用的,虽然我不习惯在生产产品中使用它.所需的思维转变是重要的,所以我怀疑它会流行,除非它在实际应用中显示出令人信服的好处.我一直听说未来是在大规模并行计算中,因为CPU在核心中开始加倍,就像以前的频率加倍一样.到目前为止,4核和8核桌面并没有真正显示出对一般工作负载有用.我认为我们有一个鸡蛋和鸡蛋问题：并行机器的采用正在等待能够充分利用的软件,而高度并行软件的主流开发正在等待高度并行的硬件无处不在.
我想也许所需要的是一个开源软件项目,为Web服务器之类的东西采用STM模型.像这样的成功项目将是一个很好的模型,可以通过证明STM为现实世界做好准备来帮助启动整个软件行业.