我们对事务内存的要求是否过高？
我最近阅读了很多有关事务内存的内容。 关于 TM 有一些炒作，所以很多人都对它充满热情，它确实为锁定带来的痛苦问题提供了解决方案，但你也经常会看到抱怨：
- 你不能做 I/O，
- 你必须编写你的 I/O。原子部分，这样它们就可以运行多次（小心你的局部变量！）
- 软件事务内存提供了很差的性能
- [在这里插入你的小烦恼]
我理解这些担忧：通常，你会发现有关 STM 的文章仅在某些平台上运行支持一些非常漂亮的原子操作的特定硬件（例如 LL/SC ），或者它必须得到某个想象的编译器的支持，或者它要求所有对内存的访问都是事务性的，它引入了 monad 风格的类型约束，等等。最重要的是：这些都是真正的问题。
这让我问自己：什么反对在本地使用事务内存来代替锁？这是否已经带来了足够的价值，或者如果使用事务内存，则必须在整个地方使用事务内存？
I've been reading up a lot about transactional memory lately. There is a bit of hype around TM, so a lot of people are enthusiastic about it, and it does provide solutions for painful problems with locking, but you regularly also see complaints:
- You can't do I/O
- You have to write your atomic sections so they can run several times (be careful with your local variables!)
- Software transactional memory offers poor performance
- [Insert your pet peeve here]
I understand these concerns: more often than not, you find articles about STMs that only run on some particular hardware that supports some really nifty atomic operation (like LL/SC), or it has to be supported by some imaginary compiler, or it requires that all accesses to memory be transactional, it introduces type constraints monad-style, etc. And above all: these are real problems.
This has lead me to ask myself: what speaks against local use of transactional memory as a replacement for locks? Would this already bring enough value, or must transactional memory be used all over the place if used at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，你提到的一些问题现在可能是真实的，但事情在发展。
与任何新技术一样，首先会有炒作，然后新技术表明存在一些未解决的问题，然后其中一些问题得到解决，另一些则没有解决。 这为解决您的问题提供了另一种可能性，而这项技术更适合这种情况。
我想说的是，您可以将 STM 用于应用程序的一部分，从而不受当前技术水平的限制。 例如，应用程序的一部分不介意效率损失。
事务和非事务部分之间的通信是个大问题。 有些 STM 具有锁感知能力，因此它们可以以一致的方式与非事务部分进行交互。
I/O 也是可以的，但是你的事务变得不可撤销，即不能中止。 这意味着只有一个事务可以同时使用 I/O。 一旦顶级事务成功，您也可以在非事务世界中使用 I/O，就像现在一样。
大多数 STM 库基础系统强制用户区分事务性数据和非事务性数据。 所以是的，您需要了解这到底意味着什么。 另一方面，编译器可以推断出哪些访问必须是事务性的或不是事务性的，问题是它们可能过于保守，从而降低了当我们显式管理不同类型的变量时可以获得的效率。 这与静态、局部和动态变量相同。 您需要了解每个人制定正确程序所必须受到的限制。
Yes, some of the problems you mention can be real ones now, but things evolve.
As any new technology, first there is a hype, then the new technology shows that there are some unresolved problems, and then some of these problems are solved and others not. This result in another possibility to solve your problems, for which this technology is the more adapted.
I will say that you can use STM for a part of your application that can leave with the constraints the currents state of the art have. Part of the application that don't mind about a lost of efficiency for example.
Communication between the transaction and non transactional parts is the big problem. There are STM that are lock aware, so them can interact in a consistent way with non transactional parts.
I/O is also possible, but your transaction becomes irrevocable, that is, can not be aborted. That means that only one transaction can use I/O at the same time. You can also use I/O once the top level transaction has succeed, on a non-transactional world, as now.
Most of the STM library base systems force the user to make the difference between transactional and non transactional data. So yes, you need to understand what this exactly means. On the other hand, compilers can deduce what access must be transactional or not, the problem been that they can be too conservative, decreasing the efficiency we can get when we manage explicitly the different kind of variables. This is the same as having static, local and dynamic variables. You need to know the constraints each one have to make a correct program.
您可能也对此感兴趣 关于软件事务内存的播客，其中还使用基于垃圾收集的类比来介绍 STM：
You might also be interested in this podcast on software transactional memory, which also introduces STM using an analogy based on garbage collection:
如果您使用事务内存作为锁的替代品，则持有该锁的所有执行代码都可以在完成后回滚。 因此，以前使用锁的代码必须是事务性的，并且将具有所有相同的缺点（和优点）。
因此，您可以将 TM 的影响限制在代码中持有锁的部分，对吧？ 在这种情况下，在持有锁期间可以调用的每一段代码都必须支持 TM。 您的程序中有多少部分不持有锁并且从未被持有锁的代码调用？
If you use transactional memory as a replacement for locks, all the code that executes with that lock held could be rolled back upon completion. Thus the code that was previously using locks must be transactional, and will have all the same drawbacks (and benefits).
So, you could possibly restrict the influence of TM to only those parts of the code that hold locks, right? Every piece of code that can be called during a held lock must support TM, in that scenario. How much of your program does not hold locks and is never called by code that holds locks?