transactions - 关于 STM 实现的问题

Question

我读过两个关于 STM 如何实现的完全不同的描述。也许两者都是正确的，或者一个是错误的，我希望有人能阐明这一点。

Take 1(维基百科):允许所有线程修改共享内存，但事务中的每次读写都会被记录下来。在事务结束时，系统检查其他线程是否没有同时对内存进行更改。如果未进行任何更改，则提交事务。否则，重新开始交易。

• 问:如果这是一个有效的实现，那么允许两个线程在同一个事务中执行似乎是没有用的。他们将读取彼此的写入，并且事务 block 内的计算将是畸形的。

Take 2(无法找到源代码):当程序进入事务时，它会获得其中包含的所有变量的副本，并可以直接使用它们。在交易结束时，系统会尝试用副本更新主服务器。如果自从第一次创建副本后 master 没有改变，那么事务就会被提交。否则，重新开始交易。

还有，两个线程同时进入同一个事务会怎样？这不会导致某种竞争条件吗？由于两者都试图修改相同的共享内存，因此两者都需要重新启动并且问题会无限期地继续，除非系统介入并告诉一个线程冷却它(有点像锁=)我确定我是这里缺少一个概念。

Answer 1

我不是专家，但读过一些论文。与新技术提案一样，一个小组似乎提出了 STM，但其他​​小组的后续工作着眼于变体。不止你说的这两个。例如，本文提供了一种机制，该机制在事务上具有阻塞锁，而不是你们两个都采用积极的非阻塞方法:http://pages.cs.wisc.edu/~david/courses/cs758/Fall2007/papers/saha-mcrt-ppopp-2007.pdf实现技术之间唯一的共同点似乎是类似数据库的事务语义。因此，研究的核心问题是这些语义是否会导致更好的程序和/或更高的总体效率。它们的实现方式有待商榷。

Also, what happens when two threads enter the same transaction at the same time? Doesn't this cause a race condition of sorts? Since both are attempting to modify the same shared memory, both will need to be restarted...

不是真的。系统总是取得进展，因为当 2 次或更多次提交发生冲突时，日志允许将所有提交回滚到冲突事务开始的点。然后可以允许线程继续并按顺序提交。你是对的，这会导致重复工作，尤其是当对单个对象的需求量很大时。然而，只有当它比上下文交换成本更高时，才值得避免这种情况。 STM 人员打赌内存冲突相对较少。维基百科方案在这个假设中特别激进。