我们对事务内存的要求是否过高？

Question

我最近阅读了很多有关事务内存的内容。关于 TM 有一些炒作，所以很多人都对它充满热情，它确实为锁定带来的痛苦问题提供了解决方案，但你也经常会看到抱怨：

• 你不能做 I/O
• 您必须编写原子部分，以便它们可以运行多次（小心您的局部变量！）
• 软件事务内存性能较差
• [在此插入您的烦恼]

我理解这些担忧：通常，您会发现有关 STM 的文章仅在某些支持某些非常漂亮的原子操作的特定硬件上运行（例如 法学学士/SC），或者它必须得到某个虚构的编译器的支持，或者它要求 全部 对内存的访问是事务性的，它引入了 monad 风格的类型约束等。最重要的是：这些都是真正的问题。

这让我问自己： 什么反对本地使用事务内存来替代锁？ 这是否已经带来了足够的价值，或者如果使用的话必须在各处使用事务内存？

Answer 1

是的，你提到的一些问题现在可能是真实的，但事情在发展。与任何新技术一样，首先会有炒作，然后新技术表明存在一些未解决的问题，然后其中一些问题得到解决，另一些则没有解决。这为解决您的问题提供了另一种可能性，而这项技术更适合这种情况。

我想说的是，您可以将 STM 用于应用程序的一部分，从而不受当前技术水平的限制。例如，应用程序的一部分不介意效率损失。

事务和非事务部分之间的通信是个大问题。有些 STM 具有锁感知能力，因此它们可以以一致的方式与非事务部分进行交互。

I/O 也是可以的，但是你的事务变得不可撤销，即不能中止。这意味着只有一个事务可以同时使用 I/O。一旦顶级事务成功，您也可以在非事务世界中使用 I/O，就像现在一样。

大多数 STM 库基础系统强制用户区分事务性数据和非事务性数据。所以是的，您需要了解这到底意味着什么。另一方面，编译器可以推断出哪些访问必须是事务性的或不是事务性的，问题是它们可能过于保守，从而降低了当我们显式管理不同类型的变量时可以获得的效率。这与静态、局部和动态变量相同。您需要了解每个人制定正确程序所必须受到的限制。

Answer 2

我最近阅读了很多有关事务内存的内容。

您可能对此也感兴趣 关于软件事务内存的播客, ，其中还使用基于垃圾收集的类比来介绍 STM：

这 纸 是关于垃圾收集和事务内存之间的类比。除了看到类比的美丽之外，讨论还可以很好地介绍交易记忆（在Goetz/Holmes插曲中提到），并且在某种程度上是垃圾收集的。

Answer 3

如果您使用事务内存作为锁的替代品，则持有该锁的所有执行代码都可以在完成后回滚。因此，以前使用锁的代码必须是事务性的，并且将具有所有相同的缺点（和优点）。

因此，您可以将 TM 的影响限制在代码中持有锁的部分，对吧？在这种情况下，在持有锁期间可以调用的每一段代码都必须支持 TM。您的程序中有多少部分不持有锁并且从未被持有锁的代码调用？