关于多线程：有没有人尝试过C ++的事务性内存？

我正在检查Intel的" whatif"站点及其事务性事务编译器(每个线程都必须进行原子提交或回滚系统的内存，就像数据库一样)。

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

我没有使用过英特尔的编译器，但是，Herb Sutter对此发表了一些有趣的评论...

从萨特讲：并发的未来

您是否对事务内存感兴趣并使用了很多事务，还是对于大多数开发人员来说，这个概念太难了？

由于尚未将其投放市场，因此尚无法回答谁在使用它。英特尔拥有软件事务性内存编译器原型。但是，如果问题是"开发人员难于使用吗？"答案是我当然希望不会。关键是它比锁更容易。这是研究视野中唯一的主要事物，它寄希望于极大地减少我们对锁的使用。它永远不会完全替换锁，但这是我们唯一希望部分替换它们。

有一些限制。特别是，某些I / O本质上不是事务性的-您不能采用原子块来提示用户输入其名称并从控制台读取名称，并且如果该I / O与另一个事务冲突，则只会自动中止并重试该块；如果您两次提示用户，则用户可以分辨出差异。事务性内存非常适合仅涉及内存的事物。

我认识的每个主要硬件和软件供应商在研发中都有多个事务存储工具。有关于基本问题的理论答案的会议和学术论文。我们还没有进入模型T阶段。您可能会看到早期有限的原型，在这些原型中，您无法执行无限制的事务性内存，在其中只能读取和写入100个内存位置。但是，这对于启用更多无锁算法仍然非常有用。

我已经在一些功能性编程思想的基础上构建了组合式STM库。它不需要任何编译器支持(除了使用C ++ 17)，也没有带来新的语法。通常，它采用Haskell的STM库的接口。

因此，我的库具有几个不错的属性：

• 单峰组合。每个事务都是名为STML的自定义monad内部的计算。您可以将单子交易合并为更大的单子交易。
• 事务与数据模型分离。您可以使用事务变量(TVars)构造并发数据模型，并在其上运行事务。
• 有retry组合器。它允许您重新运行事务。建立简短易懂的交易非常有用。
• 有不同的单子组合器可以很快表示计算。
• 有Context。每个计算都应该在某些上下文中运行，而不是在全局运行时中运行。因此，如果需要几个独立的STM群集，则可以有许多不同的上下文。
• 从概念上讲，实现非常简单。至少，Haskell中的参考实现是如此，但是由于缺少对函数式编程的良好支持，我不得不重新发明了几种C ++实现的方法。

该库显示出非常好的稳定性和鲁棒性，即使我们认为它是实验性的。而且，我的方法为通过性能，功能，全面性等改进库提供了很多可能性。

为了演示其工作，我解决了Dining Philosophers任务。您可以在下面的链接中找到代码。交易示例：

更新
我已经写了一个教程，您可以在这里找到它。

• 餐饮哲学家的任务
• 我的C ++ STM库

Dobb博士去年发表了一篇有关该概念的文章：Calum Grant的事务性编程-http://www.ddj.com/cpp/202802978

它包括使用他的示例库的一些示例，比较和结论。

Sun Microsystems宣布他们将在明年发布代号为Rock的新处理器，该处理器具有对事务性内存的硬件支持。它将有一些限制，但这是一个很好的第一步，应该使程序员可以更轻松地用事务替换锁/互斥锁，并期望其具有良好的性能。

Sun从事事务性存储和岩石研究的研究人员之一Mark Moir提供了有关该主题的有趣演讲，请查看此链接。

有关Sun总体上有关Rock和Transactional Memory的更多信息和公告，请访问此链接。

强制性维基百科条目:)

最后，该链接位于威斯康星大学麦迪逊分校，包含关于事务性存储器的已经和正在进行的大多数研究的书目，无论它是硬件还是软件。

在某些情况下，我认为这是有用的，甚至是必要的。

但是，即使处理器具有使该过程更容易的特殊指令，与互斥量或信号量相比，仍然存在较大的开销。根据实现方式的不同，它也可能会影响实时性能(必须停止中断或阻止中断写入共享区域)。

我的期望是，如果实现了此功能，则仅对于给定存储空间的某些部分才需要这样做，因此影响可能会受到限制。

-亚当