最近我一直在阅读很多关于事务性内存的文章。TM 有一些炒作，所以很多人都对它充满热情，它确实为痛苦的锁定问题提供了解决方案，但你也经常看到抱怨：
我理解这些担忧：通常情况下，您会发现有关 STM 的文章仅在某些特定硬件上运行，这些硬件支持一些非常漂亮的原子操作（如LL/SC），或者它必须由一些虚构的编译器支持，或者它需要所有对内存的访问都是事务性的，它引入了类型约束 monad 样式等。最重要的是：这些都是真正的问题。
这让我问自己：是什么反对本地使用事务内存来代替锁？这是否已经带来了足够的价值，还是必须在所有地方使用事务内存（如果使用的话）？
最近我一直在阅读很多关于事务性内存的文章。
您可能还对这个关于软件事务内存的播客感兴趣，它还使用基于垃圾收集的类比介绍了 STM：
该论文是关于垃圾收集和事务内存之间的类比。除了看到类比的美妙之处，这个讨论还很好地介绍了事务性内存（在 Goetz/Holmes 情节中提到过）和 - 在某种程度上 - 垃圾收集。
是的，你提到的一些问题现在可能是真实的，但事情会发展。就像任何新技术一样，首先是炒作，然后新技术表明存在一些未解决的问题，然后这些问题有的解决了，有的没有。这导致解决您的问题的另一种可能性，该技术更适合。
我会说您可以将 STM 用于您的应用程序的一部分，该部分可以不受当前最先进技术的约束。例如，不介意效率损失的应用程序的一部分。
事务和非事务部分之间的通信是个大问题。有些 STM 具有锁意识，因此它们可以以一致的方式与非事务性部分进行交互。
I/O 也是可能的，但您的事务变得不可撤销，即不能中止。这意味着只有一个事务可以同时使用 I/O。一旦顶级事务成功，您也可以在非事务世界上使用 I/O，就像现在一样。
大多数 STM 库基础系统都强制用户区分事务数据和非事务数据。所以是的，你需要明白这到底意味着什么。另一方面，编译器可以推断出哪些访问必须是事务性的，问题是它们可能过于保守，从而降低了我们在显式管理不同类型的变量时可以获得的效率。这与拥有静态、局部和动态变量相同。您需要了解每个人必须制定正确程序的限制条件。
如果您使用事务性内存作为锁的替代品，那么在持有该锁的情况下执行的所有代码都可以在完成时回滚。因此，以前使用锁的代码必须是事务性的，并且具有所有相同的缺点（和优点）。
因此，您可以将 TM 的影响限制在仅那些持有锁的代码部分，对吧？在这种情况下，可以在持有锁期间调用的每一段代码都必须支持 TM。您的程序中有多少没有持有锁并且从不被持有锁的代码调用？