クライアントアプリケーションの複数のスレッドについて話し合っていたところ、データの受信に別のスレッドを使用し、データの送信に別のスレッドを使用するのは方法ではないと言われました。
なんで?
私が知っていることから、TCPは全二重なので、これはパフォーマンスの向上になるのでしょうか。
専用の送信スレッドと専用の受信スレッドを持つことは、2 つの理由で良くありません。
まず、両方を同時に行っていない限り、受信から送信に移行するたびにコンテキストの切り替えが必要になることを意味します。
次に、クエリを受信し、応答を作成し、その応答を送信する典型的なパスでは、あるスレッドから別のスレッドにデータを渡す必要があり、キャッシュを吹き飛ばす必要があります。
とはいえ、パフォーマンスがそれほど重要ではなく、設計にうまく適合している場合は、確実に機能します。ただ、メリットがないのが普通です。
アプリケーションの規模にもよると思います。クラスプロジェクト用の小さなアプリを実行している場合は、同じスレッドで送信と受信を行うだけで十分な場合があります。そうすれば、スレッドの問題について心配する必要はありません。
ただし、数千の着信接続をリッスンする必要があるアプリケーションに取り組んだため、各接続が大量のデータを送信している可能性があります。ソケット接続をリッスンして新しい接続をプールに入れることを唯一の目的とするスレッドと、ソケットを読み取るためだけの可変数のスレッド(アプリのビジー状態に応じて)と、書き込み。
問題は、リスニングソケットがワイヤからデータを十分に速く読み取っていず、バッファがいっぱいになると、エラーが返され、数千のクライアントの場合、多くの再接続と再接続が発生することです。 -データの送信。これにより、そもそもデータが十分に高速に読み取られないという問題が悪化しました。
つまり、最初に言ったことに戻ります。アプリケーションの規模によって異なりますが、今すぐ機能を追加してみませんか?スレッドセーフであることを確認してください。問題がないはずです。