対称スレッドの考え方に基づいたマルチスレッド ソフトウェアを開発しています。ここでは、すべてのスレッドが同じ手順を実行します。スレッドには次の作業を行うことができます
- タイマー メッセージの処理
- ソケット fd からメッセージを受信
- send Q からメッセージを送信する
- 仕事の投票
任意のスレッドが作業を選択して実行を開始できる共有作業 Q を用意します。フリー スレッドは、利用可能な作業がないことを発見すると、作業をポーリングします。
fd からデータを読み取る間、スレッドは EAGAIN になるまで読み取りを続けます。すべての fds が同様の量のデータを取得している場合、ソフトウェアは正常に動作します。
一部の fds にさらにデータがある場合。一部のスレッドが同じ fd を処理するためにビジーであり、特定の fd が長時間処理されていません。これにより、一時的なバッファ (たとえば、EAGAIN の取得時にメッセージを保持するために使用されるバッファ) がいっぱいになり、システムが不安定になります。この問題を解決するために、(対称) スレッドが作業を取得するたびに、構成可能な数のメッセージのみを処理することを考えています。残念ながら、fds のトラフィックは予測できないため、特定のネットワーク条件に適したものにするために多くの実験が必要になる場合があります。対称スレッドがすべての fds をかなりの時間処理することを (動的に) 確実にする他の方法はありますか。ディスカッション リンク、同様のシナリオを処理した以前の経験の詳細、またはこのシナリオを処理するために開発した可能性のあるアルゴリズムを私に送っていただければ幸いです。
問題を見る別の方法は、
スレッドのプールと fds のプールがあります。一部の fd には、他よりも多くの読み取り/書き込みデータがあります。より多くのデータを持つ fds がより多くのスレッドで処理されるように、スレッドを割り当てたいと思います (ただし、同時実行の問題を解決する必要があります)。このようにして、より多くの CPU サイクルが fd に割り当てられ、より多くのデータが転送されます。この問題を解決する 1 つの方法は、fds に関する情報 (どのピアがどれだけのデータを送信するか) ですが、これは静的な情報であり、fds が想定どおりに動作する限り機能します。可能であれば、動的なスキームを開発したいと考えています。