對於這種特殊情況，我應該使用spin_lock還是mutex_lock？

在我的Linux應用程序中，我有兩個線程都嘗試使用相同的UDP客戶端套接字發送UDP廣播數據包（大約50-500字節）。他們每2-3秒做一次。在這種情況下，圍繞「發送（...）」條款，我可以放入pthread_mutex_lock或pthread_spin_lock。理論上說，如果這是一個非常小的操作，則pthread_spin_lock效率更高（儘管在很短的時間內CPU消耗量很高）。但是如果它的操作更大，那麼pthread_mutex_lock就更好了。對於這種特殊情況，我應該使用spin_lock還是mutex_lock？

發送一個被認爲「足夠小」的UDP數據包以保證使用pthread_spin_lock，或者我應該堅持使用pthread_mutex_lock？

感謝

來源

2013-02-02 G.A.

這兩個線程是否發出相同類型的數據包？必須發送這兩個數據包還是可以找到佔用的通道的一個線程跳過傳輸？ –

@Jens：是的，兩個線程發出相同類型的pkt（相同的頭文件和一些可變數據量）。傳輸不能被跳過。 –

@全部 - 其他：感謝所有的答案。所有似乎都解決了像send（）這樣的系統調用的情況。那麼更通用的問題是：在用戶空間中是否有使用螺旋鎖的情況？ –

如果只需要鎖定是因爲它們都在同一個套接字上發送，那麼根本就不需要鎖定 - 兩個線程同時在同一個UDP套接字上調用send()是可以接受的。發送的數據不會交錯。

來源

2013-02-02 22:23:41 caf

您使用自旋鎖，而不是互斥避免哪些是避免進入一個系統調用中的擁塞的情況。如果您在關鍵部分使用網絡層，無論如何，您將會進入系統調用。所以就我所知，在這裏使用螺旋鎖沒有多大意義。

來源

2013-02-02 22:19:49

在螺旋鎖中包裝系統調用是個壞主意。在任何情況下，在用戶空間應用程序中使用自旋鎖的優點都是有問題的。 Linux的互斥鎖實現（使用futexes）非常高效 - 尤其是在鎖未經驗證的情況下，在設計良好的MT應用程序中幾乎總是如此。

其他人指出，send函數本身是線程安全的。

來源

2013-02-02 22:37:33

對於這種特殊情況，我應該使用spin_lock還是mutex_lock？

回答

相關問題