私の Linux アプリには、同じクライアント ソケットUDPを使用してブロードキャスト パケット (約 50 ～ 500 バイト) を送信しようとする 2 つのスレッドがあります。UDP彼らはこれを2〜3秒ごとに約1回行います。この場合、「send(...)」句の周りにpthread_mutex_lockorを置くことができpthread_spin_lockます。理論によると、非常に小さな操作であれば、a のpthread_spin_lock方が効率的です (その短い時間で CPU の消費量が多いにもかかわらず)。しかし、それpthread_mutex_lockがより大きな操作である場合は、より良いです。
UDPを使用することを保証するのに「十分に小さい」と見なされるパケットを送信していますかpthread_spin_lock、それとも引き続き を使用する必要がありpthread_mutex_lockますか?
ありがとう
両方が同じソケットで送信しているという理由だけでロックが必要な場合は、ロックする必要はまったくありません。2 つのスレッドがsend()同じ UDP ソケットで同時に呼び出すことは許容されます。送信されるデータはインターリーブされません。
システム コールをスピンロックでラップするのはよくありません。いずれにせよ、ユーザー空間アプリでスピンロックを使用するメリットは疑問です。Linux のミューテックス実装 ( futexを使用) は非常に効率的です。特に、適切に設計された MT アプリではほとんどの場合、ロックが競合していない場合に有効です。
send他の人は、関数自体がスレッドセーフであることを指摘しています。
ミューテックスの代わりにスピンロックを使用することで回避できるのは、輻輳が発生した場合にシステムコールに入らないようにすることです。クリティカル セクションでネットワーク層を使用している場合は、システム コールが発生します。私が見る限り、ここではスピンロックを使用してもあまり意味がありません。