原子操作与 STM

发布于 2024-11-09 16:30:00 字数 364 浏览 2 评论 0原文


我正在尝试对这两个(软件事务内存和原子操作,我想两者不一样)进行一些基准测试,尽管我没有使用STM做太多事情(它似乎很难使用),但我成功地尝试了计算基准测试,即所有线程将共享计数器递增 5000 万次,并注意到原子操作比 STM 效果更好。
所以我想知道,由于STM尚未完全开发,它们在现实情况下是否比原子操作表现得更好?
是否有人因为性能原因而转向其他人?请分享信息..
我在网上找到的相关期刊是无锁并发编程

PS I我使用 JAVA 作为编程语言。 STM:- 多元宇宙。原子操作:原子整数。

I was trying some benchmark over these two ( Software transactional memory & Atomic Operation , i guess both are not same ), though i have not done much using STM ( it seems hard to use ) ,but i successfully tried counting benchmark i.e. all the threads are incrementing a shared counter 50mn times, and noticed that atomic operation works better than STM.

So i want to know since STM are not fully developed , do they perform well in realistic situation than Atomic operation?
Has some one switched to other because of performance ? please share the information..

related journal i found on the web is Concurrent programming without locks

P.S. I am using JAVA as programming language. STM :- multi-verse. AtomicOperatinn: AtomicInteger.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

千秋岁 2024-11-16 16:30:00

原子操作和 STM 是非常不同的东西。特别是,原子操作是“较低级别”的构造 - 事实上,各种类型的原子操作通常用于实现 STM。基本上:

  • 原子操作允许您对单个对象进行并发安全更新。这既简单又快速,通常只需现代硬件上的一条指令即可。
  • STM 允许您对多个对象进行并发安全更新。这很复杂。

因此,STM 系统需要增加额外的簿记开销来管理事务更新的复杂性 - 因此,如果您只需要更新单个对象,原子操作几乎总是会更快。

另外,您应该意识到,对于设计 STM 系统的最佳方法还没有达成共识 - 这是一个活跃的研究主题,并且涉及许多权衡。因此,在一个 STM 系统上表现良好的系统可能在另一个 STM 系统上表现不佳,等等。

例如:我目前最喜欢的 STM 系统是Clojure 的 - 它特别有吸引力,因为它支持多版本并发控制并且从不妨碍读者 - 这在许多常见场景中提供了显着的性能优势。

Atomic operations and STMs are very different beasts. In particular, atomic operations are much "lower level" constructs - in fact, atomic operations of various kinds are generally used to implement STM. Basically:

  • An atomic operation allows you to do a concurrency-safe update of a single object. This is easy and fast, typically just a single instruction on modern hardware.
  • STM allows you do to a concurrency-safe update of multiple objects. This is complex.

STM systems therefore need to add additional book-keeping overhead to manage the complexity of a transactional update - so if you only need to update a single object an atomic operation will nearly always be faster.

Also, you should be aware that there is no consensus on the best way to design STM systems - it's an active research topic and there are many tradeoffs involved. So what performs well on one STM system might not perform well on another STM system etc.

For example: my favourite STM system at the moment is Clojure's - it's particularly appealing because it supports multi-version concurrency control and never impedes readers - which gives a significant performance advantage in many common scenarios.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文