我们是否要求太多事务性内存?

是的,你提到的一些问题现在可能是真的,但是事情在发展。 作为任何一种新技术,首先有一个炒作,然后新技术表明有一些尚未解决的问题,然后这些问题中的一些得到了解决,而另一些没有得到解决。这就产生了另一种解决问题的可能性,这种技术更适合解决问题。

我要说的是,您可以对应用程序的一部分使用stm,这样可以保留当前技术状态所具有的约束条件。例如,应用程序中不介意效率损失的部分。

事务与非事务部分之间的通信是一个大问题。有一些支持锁的STM,因此它们可以以一致的方式与非事务性部分进行交互。

I/O也是可能的,但您的交易不可撤销,即不能中止。这意味着只有一个事务可以同时使用I/O。您也可以在顶级事务成功后使用I/O,就像现在这样,在非事务性的环境中。

大多数STM库基础系统强制用户在事务性数据和非事务性数据之间进行区分。所以是的,你需要明白这到底意味着什么。另一方面,编译器可以推断出哪些访问必须是事务性的或非事务性的,问题是它们可能过于保守,当我们显式地管理不同类型的变量时,会降低效率。这与静态变量、局部变量和动态变量相同。你需要知道约束条件,每个约束都必须制定一个正确的程序。

最近我读了很多关于事务性内存的文章。

你也可能对这个感兴趣 podcast on software transactional memory ,它还使用基于垃圾收集的类比引入STM:

这个 paper 是关于垃圾收集和事务性内存之间的类比。 除了看到类比的美之外,讨论也起到了很好的作用。 事务性记忆介绍(在Goetz/Holmes的一集中提到) 在某种程度上,还有垃圾收集。

如果将事务性内存用作锁的替换,则在完成时可以回滚使用该锁执行的所有代码。因此,以前使用锁的代码必须是事务性的,并且具有所有相同的缺点(和好处)。

所以,您可以将tm的影响限制为只包含锁的代码部分,对吗?在这种情况下,在保持锁期间可以调用的每段代码都必须支持tm。有多少程序不持有锁,并且从不被持有锁的代码调用?