问题标签 [transactional-memory]

我正在查看英特尔的“whatif”站点和他们的事务内存编译器（每个线程都必须进行原子提交或回滚系统内存，就像数据库一样）。

这似乎是替换锁和互斥锁的一种有前途的方法，但我找不到很多推荐。这里有人有意见吗？

我处于编程语言的设计阶段，目前正在考虑并发方面。我需要找出一个一致性模型，即用这种语言编程的并发进程如何处理数据。

有两个重要的标准：

• 我更喜欢易用性而不是性能，只要一致性模型允许良好的扩展，
• 我不能使用需要阻塞或动态内存分配的一致性模型。

我现在的两个候选人一方面是非阻塞软件事务内存，另一方面是在不共享la Erlang的情况下复制消息传递语义。

我特别担心易用性，所以我将介绍我反对这两个模型的主要论点。

在 STM 的情况下，用户必须了解类的哪些成员必须以原子方式改变并正确界定原子代码段。这些必须写成可以重复未定义的次数，它们不能执行任何 I/O，不能调用一些外部函数等。我认为这对于没有经验的程序员来说远非易事。

Erlang 风格的无共享并发很有吸引力，但有一个问题：实时进程无法复制它们发送过来的对象，因为它们无法执行任何内存分配，因此对象必须从一个进程“移动”到另一个进程通过队列。用户必须知道，如果一个实时进程对一个对象有两个引用，那么如果他将对象发送到另一个进程，这两个引用都将被清除。这有点像在任何使用点都可能为空或不为空的弱指针：这可能令人惊讶。

我倾向于第二种模型，因为它看起来更容易理解，并且自然地扩展到分布式系统。

你有什么建议吗？

• 非阻塞软件事务内存？
• Erlang 风格的并发具有实时约束的困难？
• 还有什么我没有考虑过的？

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

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

我理解这些担忧：通常情况下，您会发现有关 STM 的文章仅在某些特定硬件上运行，这些硬件支持一些非常漂亮的原子操作（如LL/SC），或者它必须由一些虚构的编译器支持，或者它需要所有对内存的访问都是事务性的，它引入了类型约束 monad 样式等。最重要的是：这些都是真正的问题。

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

我一直在研究事务性内存及其对系统编程（数据库、操作系统、服务器等）的可行性。我自己使用事务的经验，以及看到很少有社区在实际代码中使用事务，提出了一个问题：什么会说服你，一个编写生产代码的开发人员，在你的工作中使用事务内存？

会是普遍采用吗？高速？提高可靠性？多少？

对于那些还没有见过它们的人，内存事务就像数据库事务一样：操作（显然）并行进行，如果两个事务之间存在冲突（例如它们都写入相同的值），那么其中一个或两个事务将被回滚并重新启动。

事务性内存有几个好处：

1. 可靠性完全摆脱死锁（例如错误顺序锁定）。
2. 性能锁争用较少时速度更快。
3. 可编程性 细粒度的并发控制，无需管理许多同步对象。

然而，即使假设 TM 的实现正确、完整和快速，与锁相比，这个原语也存在已知的缺点。

1. 由于事务可能会执行多次，因此除了通过经验实验之外，更难预测性能。

   我们可以重现性能错误吗？

2. 在正确的实现之间存在一些不同的策略决策，例如，在另一个事务中结束的事务会发生什么？我们现在承诺，还是等待？

   我们能否充分理解代码的局部影响？

3. 为了在回滚的事务中支持不可撤销的行为（例如发送“发射导弹”命令），运行时变得更加复杂。

   我们能否充分理解代码的全局影响？

最后，由于软件实现可能是第一个被使用的（C、C++、Haskell、Clojure 和 Scala 等已经有实现），实际上存在性能问题。在适度争用的情况下，软件事务会带来性能损失。

你的绩效预算是多少？什么时候收益大于潜在成本？

考虑以下 Erlang 代码：

输出是：

final由于先前的接收模式与该消息不匹配，消息的处理基本上被推迟到最后一个接收块。

你如何用 Haskell 的 TChan 做到这一点？

我已经阅读了很多关于软件事务内存的内容，尤其是与 Haskell 相关的内容，但我试图弄清楚它与数据库事务有何不同？STM有一些我不了解的优点吗？

这只是一个假设的场景来说明我的问题。假设它们之间共享两个线程和一个 TVar。在一个线程中有一个原子块读取 TVar 并需要 10 秒才能完成。在另一个线程中是一个原子块，它每秒修改一次 TVar。第一个原子块会完成吗？当然它会一直回到开头，因为日志永远处于不一致的状态？

据我了解，有几种不同的算法可以实现软件事务内存（这是一个非常活跃的研究领域）。我在哪里可以找到（无需深入研究源代码）在不同语言和库中使用的，特别是在 Clojure 和 Haskell (GHC) 中？

我试图找出 Clojure 所称的 STM 与 Haskell 中实现的 STM 之间的区别。撇开实际的语言语义差异不谈，正如 Rich Hickey 在他的演讲中所说，Clojure 的 STM 实现与其他任何东西都非常不同，但我不理解除了语言选择之外的差异。

我一直在理解 STM 中原子的概念。

我举例说明

示例输出将如下所示：

添加结果 1 True 添加结果 4 False 添加结果 1 False 结果添加 2 FalseResult 添加 3 False Hello World？添加的结果 4 False

add in 1 的结果 False add in 2 的结果 False add in 3 的结果 False add in 4 的结果 False

add in 1 的结果 False add in 2 的结果 False add in 3 的结果 False add in 4 的结果 False

add in 1 的结果 False add in 2 的结果 False add in 3 的结果 False add in 4 的结果 False

add in 1 的结果 False add in 2 的结果 False add in 4 的结果 False add in 3 的结果 False

add in 1 的结果 False add in 4 的结果 False add in 2 的结果 False add in 3 的结果 False

add in 1 的结果 False add in 4 的结果 False add in 2 的结果 False add in 3 的结果 False

add in 1 False 结果 add in 4 False

add in 2 False 结果 add in 3 False

add in 1 False 结果 add in 4 False

添加结果 2 False 添加结果 3 False 添加结果 1 False 添加结果 4 False

add in 2 False 结果 add in 3 False

add in 1 False 结果 add in 4 False

当我读到原子

. 这意味着事务中的所有操作完全完成，没有任何其他线程修改我们的事务正在使用的变量，否则它会失败，并且状态会回滚到事务开始之前的位置。简而言之，原子事务要么完全完成，要么就好像它们从未运行过一样。

那么对于这个问题，在某些情况下，成功的“回归”可能永远不会发生吗？那可以是 succ <- atomically $ runAdd d putStrLn $"Result of add in " ++ (show i)++ " " ++( show succ)

给出“添加结果？i”的输出（“好像它们根本没有运行”）