gpt4 book ai didi

c++ - 关于无锁编程的一些疑惑

转载 作者:太空宇宙 更新时间:2023-11-04 06:39:33 25 4
gpt4 key购买 nike

<分区>

嗨伙计们,
首先抱歉,这将是一个中等长度的帖子。所以,请耐心阅读。

在这里,我将记下我在浏览一些有关无锁编程的文章时学到的一些概念,并提出我对这些知识的疑惑。
此外,讨论是关于 *NIX 多处理器平台的。

首先说“LOCKLESS = BLOCKLESS”,因为据说线程系统作为一个整体取得进展,因为 CAS/DCAS 只有在某些线程取得进展时才会失败。
因此,我们可以说,在互斥量阻塞的情况下,我们正在旋转/等待一个条件(例如 CAS while 循环)。

Quest1 > How would spinning on a while loop be more efficient than blocking on a
mutex ?
Quest2 > A good design employing mutexes also ensure that system progresses, so
isnt that BLOCKLESS too by definition?

作为问题 1 的答案,有人会争辩说,阻塞可能会进入内核等待状态,并且可能会有代价高昂的上下文切换。任何进一步的澄清将不胜感激。

好吧,假设在得到前 2 个问题的答案后,我会确信当要完成的原子操作不是很大/不耗时时,无锁确实是快速和实时的。< br/>

Quest3 > So, isnt lock-free something like spinlock ? If yes, why cant we use 
pthread spin lock ?

继续前进,在网络上可用的大多数文献中,人们会看到这样一种原子操作的实现:

__asm__ __volatile__("lock\nxadd" X " %0,%1"                                                                         : "=r"(result),"=m"(*(T *)i_pAddress)                                                                      : "0"(i_addValue)                                                                                        : "memory");  // What does this mean ? Memory Fencing ?
Quest4 > Does ":memory" in the above assemble mean memory fencing ? If yes, 
doesnt that take around 100 cycles to implement ?
Quest5 > Doesnt the lock instruction here assert that the operation is being
done on a shared resource, thus other threads are blocking here ?
As far as I know
this question is not valid for the more or less recent Intel multi proc arch
as the locking is done on cache lines.

提前致谢。

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com