什么时候使用pthread_spin_lock是正确的(例如pthread互斥锁)？

Question

鉴于pthread_spin_lock可用,我什么时候可以使用它,什么时候不应该使用它们？

即我如何决定使用pthread互斥锁或pthread自旋锁来保护某些共享数据结构？

Answer 1

简短的回答是,当您计划在极短的时间间隔内保持锁定时,螺旋锁可以更好(例如,除了增加计数器之外什么都不做),并且预计争用很少,但操作经常发生到足以是一个潜在的性能瓶颈.螺旋锁相对于互斥锁的优点是:

1. 解锁时,无需检查其他线程是否正在等待锁定并将其唤醒.解锁只是一个单一的原子写指令.
2. 无法立即获得锁定不会使您的线程进入休眠状态,因此一旦可用,它就可以以更低的延迟获得锁定.
3. 进入内核空间进入睡眠或唤醒其他线程不存在缓存污染的风险.

如果您认为好的互斥实现可能会在请求内核寻求帮助之前旋转相当多的次数,那么第1点将始终有效,但第2点和第3点的实用性略有下降.

现在,答案很长:

在使用自旋锁之前你需要问自己的是,这些潜在优势是否超过了一个罕见但非常真实的缺点:当锁定线程在释放锁之前被调度程序中断时会发生什么.这当然很少见,但即使锁只是为单个变量递增操作或其他同样重要的操作,它也可能发生.在这种情况下,尝试获取锁定的任何其他线程将继续旋转,直到保持锁定的线程被调度并有机会释放锁定.如果尝试获取锁的线程具有比持有锁的线程更高的优先级,则可能永远不会发生这种情况.这可能是一个极端的情况,但即使没有不同的优先级,在锁定所有者再次安排之前可能会有很长的延迟,最糟糕的是,一旦这种情况开始,它可以迅速升级尽可能多的线程,所有希望获取锁定,开始旋转,占用更多的处理器时间,并进一步延迟可能释放锁定的线程的调度.

因此,我会小心螺旋锁...... :-)

Answer 2

自旋锁是一个"忙碌的等待"锁.它的主要优点是它保持线程活动并且不会导致上下文切换,所以如果你知道你只会等待很短的时间(因为你的关键操作非常快),那么这可能会提供更好的性能而不是互斥体.相反,如果关键部分需要很长时间并且需要上下文切换,则互斥锁将对系统产生较少的需求.

TL; DR:这取决于.

Answer 3

性能提升最安全的方法是两者的混合:自适应互斥.

当您的系统有多个内核时,您会旋转几千个周期以捕获低或无争用的最佳情况,然后推迟到完全互斥锁以获得其他线程以进行长期争用锁定.

POSIX(PTHREAD_MUTEX_ADAPTIVE_NP)和Win32(SetCriticalSectionSpinCount)都有自适应互斥锁,许多平台没有POSIX自旋锁API.