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信號量確實有一個 ，並且就我而言只有一個 ，優於更復雜的原語，如互斥和條件變量： sem_post需要是異步信號安全的。 它是唯一的同步相關函數，它是異步信號安全的，它可以在信號處理程序的線程之間執行最小的交互！ - 如果沒有像管道或SysV IPC這樣的重量較大的工具，這些工具本身是不可能的，這些工具與性能導向的pthread習語不能很好地交互。

編輯：供參考， pthread_mutex_trylock最簡單的實現：

if (mutex->type==PTHREAD_MUTEX_DEFAULT) return atomic_swap(mutex->lock, EBUSY);
else /* lots of stuff to do */

以及sem_trywait最簡單的實現：

int val = sem->val;
return (val>0 && atomic_compare_and_swap(sem->val, val, val-1)==val) ? 0 : EAGAIN;

假設一個最佳實現，我猜想互斥鎖可能會稍微快一點，但再次對它進行基准測試。

Answer 4

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