有人尝试过 C++ 的事务内存吗?
我正在查看英特尔的“whatif”网站及其事务内存编译器(每个线程必须进行原子提交或回滚系统内存,就像数据库一样)。
这似乎是一种替代锁和互斥体的有前途的方法,但我找不到很多推荐。 这里有人有任何意见吗?
I was checking out Intel's "whatif" site and their Transactional Memory compiler (each thread has to make atomic commits or rollback the system's memory, like a Database would).
It seems like a promising way to replace locks and mutexes but I can't find many testimonials. Does anyone here have any input?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我基于一些函数式编程思想构建了组合 STM 库。 它不需要任何编译器支持(除了它使用 C++17),也不会带来新的语法。 一般来说,它采用Haskell的STM库的接口。
所以,我的库有几个很好的属性:
STML
的自定义 monad 内的计算。 您可以将单子交易组合成更大的单子交易。TVars
) 构建并发数据模型,并对其运行事务。重试
组合器。 它允许您重新运行事务。 对于构建简短且易于理解的交易非常有用。上下文
。 每个计算都应该在某个上下文中运行,而不是在全局运行时中运行。 因此,如果您需要多个独立的 STM 集群,则可以拥有许多不同的上下文。即使我们认为它是实验性的,该库也显示出非常好的稳定性和鲁棒性。 此外,我的方法为通过性能、功能、全面性等来改进库提供了很多可能性。
为了演示其工作,我解决了
Dining Philosophers
任务。 您可以在下面的链接中找到该代码。 交易示例:更新
我写了一个教程,您可以在此处找到它。
I've built the combinatorial STM library on top of some functional programming ideas. It doesn't require any compiler support (except it uses C++17), doesn't bring a new syntax. In general, it adopts the interface of the STM library from Haskell.
So, my library has several nice properties:
STML
. You can combine monadic transactions into more big monadic transactions.TVars
) and run transactions over it.retry
combinator. It allows you to rerun the transaction. Very useful to build short and understandable transactions.Context
. Every computation should be run in some context, not in the global runtime. So you can have many different contexts if you need several independent STM clusters.The library shows very nice stability and robustness, even if we consider it experimental. Moreover, my approach opens a lot of possibilities to improve the library by performance, features, comprehensiveness, etc.
To demonstrate its work, I've solved the
Dining Philosophers
task. You can find the code in the links below. Sample transaction:UPDATE
I've wrote a tutorial, you can find it here.
Sun Microsystems 宣布他们将于明年发布一款代号为 Rock 的新处理器,该处理器具有对事务内存的硬件支持。 它会有一些限制,但这是一个很好的第一步,应该使程序员更容易用事务替换锁/互斥体并期望从中获得良好的性能。
有关该主题的有趣演讲,由 Sun 公司研究事务内存和 Rock 的研究人员之一 Mark Moir 发表,请查看此 链接。
有关 Sun 有关 Rock 和事务内存的更多信息和公告,请访问此 链接。
强制性的 wikipedia 条目 :)
最后,此链接,位于威斯康星大学麦迪逊分校,包含已经和正在发生的大部分研究的参考书目正在对事务内存进行处理,无论是与硬件相关还是与软件相关。
Sun Microsystems have announced that they're releasing a new processor next year, codenamed Rock, that has hardware support for transactional memory. It will have some limitations, but it's a good first step that should make it easier for programmers to replace locks/mutexes with transactions and expect good performance out of it.
For an interesting talk on the subject, given by Mark Moir, one of the researchers at Sun working on Transactional Memory and Rock, check out this link.
For more information and announcements from Sun about Rock and Transactional Memory in general, this link.
The obligatory wikipedia entry :)
Finally, this link, at the University of Wisconsin-Madison, contains a bibliography of most of the research that has been and is being done about Transactional Memory, whether it's hardware related or software related.
在某些情况下,我认为这是有用的,甚至是必要的。
然而,即使处理器具有使该过程更容易的特殊指令,与互斥锁或信号量相比,仍然存在很大的开销。 根据其实现方式,它也可能会影响实时性能(必须停止中断,或阻止它们写入您的共享区域)。
我的期望是,如果实现了这一点,那么只需要给定内存空间的一部分,因此影响可能是有限的。
-亚当
In some cases I can see this as being useful and even necessary.
However, even if the processor has special instructions that make this process easier there is still a large overhead compared to a mutex or semaphore. Depending on how it's implemented it may also impact realtime performance (have to either stop interrupts, or prevent them from writing into your shared areas).
My expectation is that if this was implemented, it would only be needed for portions of a given memory space, though, and so the impact could be limited.
-Adam
Dobb 博士去年有一篇关于这个概念的文章:Calum Grant 的事务性编程 -- http://www .ddj.com/cpp/202802978
它包括使用他的示例库的一些示例、比较和结论。
Dr. Dobb's had an article on the concept last year: Transactional Programming by Calum Grant -- http://www.ddj.com/cpp/202802978
It includes some examples, comparisons, and conclusions using his example library.
我没有使用过英特尔的编译器,但是,Herb Sutter 对它有一些有趣的评论...
来自 Sutter 演讲:并发的未来
您是否看到人们对事务内存有很多兴趣和使用,或者这个概念对于大多数开发人员来说太难掌握?
目前还无法回答谁正在使用它,因为它尚未推向市场。 英特尔有一个软件事务内存编译器原型。 但如果问题是“对于开发者来说是不是太难用了?” 答案是我当然希望不会。 重点是它比锁容易得多。 这是研究领域中唯一有望大大减少锁的使用的重大事情。 它永远不会完全取代锁,但部分取代锁是我们唯一的希望。
有一些限制。 特别是,某些 I/O 本质上不是事务性的 - 您不能采用提示用户输入姓名的原子块并从控制台读取该名称,并且如果与另一个事务冲突,则自动中止并重试该块; 如果您提示两次,用户就能分辨出差异。 不过,事务性内存对于只涉及内存的东西来说非常有用。
据我所知,每个主要的硬件和软件供应商都在研发中拥有多种事务内存工具。 有关于基本问题的理论答案的会议和学术论文。 我们还没有达到可以发货的 T 型车阶段。 您可能会看到早期的有限原型,您无法执行无限制的事务内存,例如只能读写 100 个内存位置。 不过,这对于启用更多无锁算法仍然非常有用。
I have not used Intel's compiler, however, Herb Sutter had some interesting comments on it...
From Sutter Speaks: The Future of Concurrency
Do you see a lot of interest in and usage of transactional memory, or is the concept too difficult for most developers to grasp?
It's not yet possible to answer who's using it because it hasn't been brought to market yet. Intel has a software transactional memory compiler prototype. But if the question is "Is it too hard for developers to use?" the answer is that I certainly hope not. The whole point is it's way easier than locks. It is the only major thing on the research horizon that holds out hope of greatly reducing our use of locks. It will never replace locks completely, but it's our only big hope to replacing them partially.
There are some limitations. In particular, some I/O is inherently not transactional—you can't take an atomic block that prompts the user for his name and read the name from the console, and just automatically abort and retry the block if it conflicts with another transaction; the user can tell the difference if you prompt him twice. Transactional memory is great for stuff that is only touching memory, though.
Every major hardware and software vendor I know of has multiple transactional memory tools in R&D. There are conferences and academic papers on theoretical answers to basic questions. We're not at the Model T stage yet where we can ship it out. You'll probably see early, limited prototypes where you can't do unbounded transactional memory—where you can only read and write, say, 100 memory locations. That's still very useful for enabling more lock-free algorithms, though.