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