sem_post / sem_wait是否明显快于pthread_mutex_lock / pthread_mutex_unlock？

Question

我有一段需要快速运行的代码，现在我正在使用pthread_mutex_lock/pthread_mutex_unlock来同步线程，但我发现它对性能有一定的影响。我徘徊，如果有人对此进行基准测试，sem_post/sem_wait 显着比pthread_mutex_lock/pthread_mutex_unlock更快？

谢谢！

Answer 1

不，它不明显更快。它们使用相同的低级原语（读取自旋锁和系统调用）来实现。但真正的答案只是在你的特定情况下进行比较。

Answer 2

我会说信号量可能比互斥量慢，因为信号量具有互斥行为的超集。您可以尝试在用户级别执行某些操作，例如在没有内核支持的情况下运行的自旋锁，但这一切都取决于锁定/解锁的速率和争用。

Answer 3

我希望它们的速度大致相同，但如果您真的关心的话，您可以自己对它进行基准测试。话虽如此，POSIX信号量确实有一个，并且就我而言只有一个，优于更复杂的原语，如互斥和条件变量：{{1需要是异步信号安全的。它是仅与同步相关的函数，它是异步信号安全的，它可以在信号处理程序的线程之间执行最小的交互！ - 如果没有像管道或SysV IPC这样的重量较大的工具，这些工具本身是不可能的，这些工具与性能导向的pthread习语不能很好地互动。

修改：作为参考，sem_post的最简单实现：

pthread_mutex_trylock

以及if (mutex->type==PTHREAD_MUTEX_DEFAULT) return atomic_swap(mutex->lock, EBUSY); else /* lots of stuff to do */ 的最简单实现：

sem_trywait

假设一个最佳实现，我猜想互斥锁可能稍微快一点，但再次对它进行基准测试。

Answer 4

如果您正在使用Objective C，那么您的环境可能足够接近Cocoa，以便能够使用Grand Central Dispatch，这可能会更快，而且更加容易