对于这种特殊情况，我应该使用自旋锁还是互斥锁？答案

【问题标题】：Should I use spin_lock or mutex_lock for this particular situation?对于这种特殊情况，我应该使用自旋锁还是互斥锁？
【发布时间】：2013-01-17 23:47:09
【问题描述】：

在我的 Linux 应用程序中，我有两个线程都尝试使用相同的 UDP 客户端套接字发送 UDP 广播数据包（大约 50-500 字节）。他们大约每 2-3 秒执行一次。在这种情况下，围绕“send(...)”子句，我可以输入pthread_mutex_lock 或pthread_spin_lock。理论上说，如果这是一个非常小的操作，pthread_spin_lock 会更有效（尽管 CPU 消耗量很小）。但如果是更大的操作，那么pthread_mutex_lock 更好。

发送UDP 数据包是否被认为“足够小”以保证使用pthread_spin_lock，还是应该继续使用pthread_mutex_lock？

谢谢

【问题讨论】：

两个线程发出的数据包是同一种类型的吗？是否必须同时发送两个数据包，或者发现通道被占用的线程是否可以跳过传输？
@Jens：是的，两个线程都发送相同类型的pkt（相同的标头和一些可变数量的数据）..传输不能跳过。
@All-Others：感谢所有答案。所有似乎都解决了像 send() 这样的系统调用的情况。那么一个更通用的问题是：在用户空间中使用自旋锁有什么用处吗？

标签： c pthreads mutex spinlock

【解决方案1】：

如果唯一需要锁定是因为它们都在同一个套接字上发送，那么根本不需要锁定 - 两个线程同时在同一个 UDP 套接字上调用 send() 是可以接受的。发送的数据不会交错。

【讨论】：

【解决方案2】：

使用自旋锁而不是互斥锁可以避免在发生拥塞时进入系统调用。如果您在关键部分使用网络层，无论如何您将进入系统调用。所以据我所知，在这里使用自旋锁没有多大意义。

【讨论】：

【解决方案3】：

将系统调用包装在自旋锁中是个坏主意。在任何情况下，在用户空间应用程序中使用自旋锁的优点都是值得怀疑的。 Linux 的互斥锁实现（使用futexes）非常有效——尤其是当锁是无争议的时，在精心设计的 MT 应用程序中几乎总是如此。

其他人指出send 函数本身是线程安全的。

【讨论】：