【问题标题】:Standard C++ transactional memory status标准 C++ 事务内存状态
【发布时间】:2016-12-26 10:14:33
【问题描述】:

C++17 的事务性内存提案的当前状态是什么。它会被包含在标准中,旨在包含在标准 C++ 的某些未来版本中,还是只是一个实验性的概念验证功能,其标准化状态仍未确定?

我之所以这么问,是因为标准化委员会的一些文件在这里似乎给出了相互矛盾的沟通。一方面我们有 P0265R0 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0265r0.pdf) 说事务内存不会被标准化,另一方面 - Stroustrup (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4492.pdf) 有一篇 N4492 论文,其中事务内存列在 C++17 功能列表中.

【问题讨论】:

    标签: c++ c++17 transactional-memory


    【解决方案1】:

    很快:事务性内存 TS 已经发布,第二个版本正在开发中。但是,委员会不打算将其纳入标准中的近特征。这种选择有几个原因:

    • 没有足够的实施经验。自 GCC6 以来,只有 g++ 实现了它。 TS 的目标部分是为了收集实现和用户体验,所以这么大的功能在这方面还太“不成熟”。

    • 并非每个目标都支持事务性内存,而且它的实施成本很高,但并不是每个人都需要它。由于这些原因,委员会显然不确定 TS 是否应该成为主要 C++ 标准的一部分。它还不如永远作为 TS 存在。

    • 此外,并非所有人都认为事务性内存 TS 的每个功能都值得包含在主要的 C++ 标准中。一些人发现synchronized 是主要功能,而另一些人则认为原子块是真正的游戏规则改变者。 TS确实增加了库实现者必须处理的另一个认知开销(以及几个新的关键字,这通常不被视为一件好事)。

    【讨论】:

    • 好答案。不过,这是一种耻辱,因为它是唯一的可组合技术,AFAICT。基本上,并发编程感觉就像 15 年前一样,一切都需要从头开始编码(同样,因为没有什么是可组合的,所以周围没有可重用的构建块)。
    • @AmiTavory 交易比什么东西更可组合,为什么?
    • @JanusTroelsen 假设您发现某个项目显示了一些使用互斥锁或无锁原语的哈希表的超酷并发算法。然后你会发现一个链表也是一样的。然后,您想使用哈希表和链表构建 LRU 缓存。 AFAIU,这些解决方案的组合,并不是问题组合的解决方案(哈希表和列表并发是不够的;LRU 状态可能不一致)。但是,使用 TSM 哈希表和链表,您可以轻松构建 TSM LRU。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-07
    • 2017-10-15
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多