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