【问题标题】:Has anyone tried transactional memory for C++?有没有人尝试过 C++ 的事务性内存?
【发布时间】:2010-09-10 02:18:52
【问题描述】:

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

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

【问题讨论】:

标签: c++ multithreading locking intel transactional-memory


【解决方案1】:

我没用过 Intel 的编译器,不过 Herb Sutter 上面有一些有趣的 cmets...

来自Sutter Speaks: The Future of Concurrency

您是否看到了对事务内存的大量兴趣和使用情况,或者这个概念对于大多数开发人员来说太难掌握了吗?

目前还无法回答谁在使用它,因为它还没有上市。英特尔有一个软件事务内存编译器原型。但如果问题是“开发人员使用起来是否太难了?”答案是我当然希望不会。关键是它比锁更容易。这是研究范围内唯一希望大大减少我们对锁的使用的主要事物。它永远不会完全取代锁,但部分取代它们是我们唯一的大希望。

有一些限制。特别是,一些 I/O 本质上不是事务性的——你不能采用一个原子块来提示用户输入他的名字并从控制台读取名字,如果它与另一个事务冲突,就自动中止并重试该块;如果您提示他两次,用户可以分辨出区别。不过,事务性内存非常适合只涉及内存的东西。

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

【讨论】:

【解决方案2】:

博士。 Dobb 去年有一篇关于这个概念的文章:Calum Grant 的 Transactional Programming -- http://www.ddj.com/cpp/202802978

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

【讨论】:

    【解决方案3】:

    我在一些函数式编程思想的基础上构建了组合 STM 库。它不需要任何编译器支持(除了它使用 C++17),不会带来新的语法。一般采用Haskell的STM library的接口。

    所以,我的库有几个不错的属性:

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

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

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

    STML<bool> takeFork(const TVar<Fork>& tFork)
    {
        STML<bool> alreadyTaken = withTVar(tFork, isForkTaken);
        STML<Unit> takenByUs    = modifyTVar(tFork, setForkTaken);
        STML<bool> success      = sequence(takenByUs, pure(true));
        STML<bool> fail         = pure(false);
        STML<bool> result       = ifThenElse(alreadyTaken, fail, success);
        return result;
    };
    

    更新 我写了一个教程,你可以找到它here

    【讨论】:

      【解决方案4】:

      Sun Microsystems 宣布他们将于明年发布一款代号为 Rock 的新处理器,该处理器具有对事务内存的硬件支持。它会有一些限制,但这是一个很好的第一步,它应该让程序员更容易用事务替换锁/互斥锁期望它有良好的性能。

      有关该主题的有趣演讲,由 Sun 的事务性记忆和摇滚研究人员之一 Mark Moir 发表,请查看link

      如需 Sun 关于 Rock 和 Transactional Memory 的更多信息和公告,请联系link

      必填wikipedia entry :)

      最后,威斯康星大学麦迪逊分校的this link 包含关于事务性内存的大部分研究的参考书目,无论是硬件相关还是软件相关。

      【讨论】:

        【解决方案5】:

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

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

        我的期望是,如果实现了这一点,那么只有给定内存空间的一部分才需要它,因此影响可能会受到限制。

        -亚当

        【讨论】:

        • 这听起来不像事务性内存......与互斥锁和信号量相比,开销是多少?
        • 有几个地方开销较高。一个明显的例子是回滚事务。它还使缓存更加困难并带来更多开销,因为所有内容都必须立即写回内存。事务内存对某些应用程序来说是个好主意,但它确实会影响系统性能,因此不应为每个应用程序和系统部署。
        • 啊,但多次重启是交易的病态情况。这与锁的病态情况(长阻塞、缓存之间弹跳)相比如何?
        • 这篇文章还在吗?
        • @JanusTroelsen:英特尔当前的实现(Broadwell/Skylake)不会阻止中断,而是中止事务。请参阅realworldtech.com/haswell-tm 了解更多关于它如何在引擎盖下工作的信息。 (AFAIK 的基本设计在 Skylake 中与 Haswell 相同,尽管 HSW 存在需要在微码更新中禁用它的错误。)基本上,它会向 L1D 缓存添加一些额外的位,并在发生任何棘手的情况时中止事务。
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2021-03-13
        • 1970-01-01
        • 1970-01-01
        • 2013-07-07
        • 2021-06-22
        • 2013-02-01
        • 1970-01-01
        相关资源
        最近更新 更多