回答:
POSIXはsend / recvをアトミック操作として定義しているため、POSIX send / recvについて話していると仮定すると、はい、複数のスレッドからそれらを同時に呼び出すことができ、動作します。
これは必ずしもそれらが並列に実行されることを意味するわけではありません。複数の送信の場合、2番目の送信は最初の送信が完了するまでブロックされる可能性があります。ソケットバッファーにデータを送信すると送信が完了するため、おそらくこれに気付かないでしょう。
SOCK_STREAMソケットを使用している場合、send / recvがメッセージの一部のみを送信または受信する可能性があるため、並列処理を行うことはあまり役に立ちません。つまり、処理が分割される可能性があります。
SOCK_STREAMソケットでのブロックの送信/受信は、少なくとも1バイトを送信または受信するまでブロックするだけなので、ブロックと非ブロックの違いは役に立ちません。
send
すぐに戻って、データが送信バッファに置かれるように、データは非同期的にネットワークにnetowrkスタックを通って外に送出されます。したがって、1つのスレッドが送信し、1つのスレッドが受信している場合、受信スレッドが最初のパケットを受信する前に、送信スレッドが多くのパケットを送信する可能性があります。完全に非同期であり、同時ではありません。
ソケット記述子は、特定のスレッドではなくプロセスに属しています。したがって、異なるスレッドの同じソケットとの間で送受信を行うことができ、OSが同期を処理します。
ただし、送信/受信の順序が意味的に重要である場合、あなた自身(それぞれのコード)は、スレッドの場合は常にそうであるように、異なるスレッドでの操作間の適切なシーケンスを保証する必要があります。
並列受信で何ができるかわかりません。3バイトのメッセージがある場合、1つのスレッドが最初の2バイトを取得し、別のスレッドが最後のバイトを取得できますが、どちらがどちらであるかを知る方法はありません。メッセージの長さが1バイトしかない場合を除き、受信する複数のスレッドで何かを確実に機能させる方法はありません。
メッセージ全体を1回の呼び出しで送信した場合、複数の送信が機能する可能性がありますが、よくわかりません。別のものを上書きできる可能性があります。そうすることによるパフォーマンス上の利点は確かにありません。
複数のスレッドが送信する必要がある場合は、同期メッセージキューを実装する必要があります。キューからメッセージを読み取る実際の送信を行う1つのスレッドと、メッセージ全体をエンキューする他のスレッドを用意します。受信でも同じことが機能しますが、受信スレッドはメッセージの形式を知っている必要があるため、メッセージを適切に逆シリアル化できます。