各プレイヤーに順番があり、何が起こっているかに「注意を払う」必要があるゲームをシミュレートする必要があります。
これまでのところ、プレイヤーごとに 2 つのスレッドが必要であることはわかっています。1 つはプレイヤーの番までスリープし、もう 1 つは注意を払います。
私の質問は次のとおりです。各プレーヤーを「フォーク」およびフォーク上のスレッドとして機能させるべきですか、それともプレーヤー用にいくつかのスレッドを作成してそれらを何らかの方法で関連付けるべきですか?
同時実行、セマフォ、スレッドを扱うのは初めてなので、良いプラクティスやプログラミング スタイルについてよくわかりません。
あなたは、この問題をめぐる巨大な宗教戦争の端にたどり着きました。
イベント駆動型プログラムは、複数のスレッドを使用して作成する必要がありますか?それとも単一のイベント ループを使用して作成する必要がありますか?
スレッド陣営は、「プレーヤー」などの個々のエンティティは、実際のスレッドとして記述した方がプログラミングが容易であり、プロセッサが不要になったときにプロセッサを明示的に放棄する可能性があると考えています。プレーヤーの状態に関する情報は、ローカル変数やプログラム カウンターにも保存できます。しかし、スレッドでは、原子性、デッドロック、および並行プログラミングのその他の楽しみについて心配する必要がある場合があります。
イベント駆動陣営は、すべてのエンティティがすべてのイベントに応答でき、そのエンティティがイベントの処理に必要な時間の間、プロセッサを完全に制御できる場合に、アプリケーション全体を正しくする方がはるかに簡単であると考えています (これには有限である方がよく、通常は短いほうがよい）。すべてのイベント ハンドラーがアトミックに実行されるため、同時実行の心配はありません。ヒープ。
スレッドの話は、エンティティが複雑な制御フローを持っている場合や、多くの抽象化を使用したい場合に効果を発揮する傾向があります。これらはどちらも、スレッドなしではコーディングが困難です。イベント ストーリーは、ハンドラーがかなり単純な場合に効果を発揮する傾向があります。すべてのハンドラーを気にせずにアトミックに実行できるのは素晴らしいことであり、エンティティ間の通信が簡素化されます。
課題を進める前に、講師が所属する宗教団体を調べてください。
スレッドについて質問されたので、Dave Hanson のC Interfaces and Implementationsにあるスレッドとチャネル ライブラリを強くお勧めします。ソフトウェアは無料で、この本は購入する価値があります。C で宿題を書く人にとって非常に役立つ他の多くのモジュールが含まれています。
各プレーヤーを「フォーク」およびフォーク上のスレッドとして動作させるべきですか、それともプレーヤー用にいくつかのスレッドを作成してそれらを何らかの方法で関連付けるべきですか?
を使用するように求められない限り、使用forkは避けたいと思います。Unix プロセス間で通信するためのメカニズムは、あまり快適に使用できるものではありません。Hanson ライブラリを入手できる場合は、プレーヤーごとにスレッドを作成し、Hanson のチャネルを使用して、プレーヤーが相互に (およびスレッドである必要があるゲーム サーバーと) 通信するようにします。
ターンベースの状況 (ゲーム) では、実際にはスレッドは必要ありません。ファイバー/コルーチンで十分です (より良い)。
「注意を払う」にはスレッドは必要ありません。再び行動する準備ができたら、状態 (-changes) にアクセスするだけです。