原子操作与 STM
我正在尝试对这两个(软件事务内存和原子操作,我想两者不一样)进行一些基准测试,尽管我没有使用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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
原子操作和 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:
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.