私は C++ で記述されたゲーム サーバーで作業しており、使用するスレッドの数とスレッド化するタスクを決定しようとしています。基本的なサーバー スケルトンは、キーボード I/O とコンソールへの出力、着信接続の受け入れ、発信接続の送信、およびゲームの「処理」で構成されます。
私が知りたいのは、どのことを別のスレッドにすべきかということです。各接続には独自のスレッドが必要ですか? これは変数であり、プロジェクトなどに依存することはわかっていますが、かなりの数のプレイヤー (可能であれば数百人) をサポートしたいと考えています。
標準的な答えは常に次のとおりです。最初に最も簡単な方法を試して、単純な方法では不十分な場合にのみパフォーマンスを向上させる方法を探してください。ただし、大規模なC ++プログラムを再構築することは苦痛な経験になる可能性があるため、事前にパフォーマンスについて推測することが適切な場合があります。
理論的には、最近のマシンではおそらく数百のスレッドで問題ありません。Linux用のNPTL実装は、私が覚えているように、何万ものスレッドでテストされました。それがあなたにとって最も簡単な実装方法であるなら、それは正しい答えかもしれません。
ただし、高性能Webサーバーなどは通常、代わりにイベント駆動型モデルを使用します。libeventのようなライブラリを考えてみましょう。同じ目的のためのC++ライブラリがあると確信しています。
個人的には、ファーストクラスの継続のない言語、または少なくともコルーチンは、この種の作業には適していないと思いますが、C言語ファミリーは、今日の作業方法であるため、出発します。:-)
良い解決策は、 スレッドプールを使用することです。
アイデアは、メインスレッドが固定数のスレッドですべての接続を均等にディスパッチできるようにすることです。優れた設計により、実行時にスレッド数を簡単に設定できます。
詳細については、こちらをご覧ください。
CPUコアよりも多くのスレッドを作成することは生産的ではなく、スレッドを追加しすぎると、スレッド間の切り替えに時間がかかるため、パフォーマンスが低下します。
たとえば、大規模なプロジェクトをコンパイルする場合（まったく同じではありませんが、どちらの場合も有効です）、CPUコアの数+1以下のスレッドを使用することをお勧めします。
非常に一般的な手法は、ゲームサーバーを1つのスレッドで実行し、各ソケットでselectを使用して複数の接続（つまりソケット）を監視することです。データが利用可能になったら、データを取得して、ゲームエンジンが取得できるように、プロデューサー/コンシューマータイプのモデルにキューに入れます。
これは決してすべてを網羅した実装ではありませんが、開始するには十分なはずです。かっこいいプロジェクトのようですね。幸運を！
接続をセットアップし、スレッドがIOの待機をブロックするような方法で接続を利用する場合は、すべての接続とキーボードを1つのスレッドで処理できるはずです。コンソールへの書き込み速度が実際にボトルネックになっている場合（少なくともウィンドウで）に見たように、コンソール出力を同じスレッドに配置したくない場合があります（つまり、コンソールウィンドウが最小化されている場合はプロセスが実行されますかなり速い）。
ゲームエンジンの動作がうまく並列化されている場合は、CPUの数が少ないスレッド（OSと他の2つのスレッド）と同じ数のスレッドを使用するように設定することをお勧めします。クライアントが同じマシンで実行されることを期待している場合、サーバーはそれを検出し、使用するスレッドの数を減らします。