Multiple threads or process with threads

I have to simulate a game where each player has turns and needs to 'pay attention' to what's going on.

So far, I know I'll need two threads for e开发者_运维百科ach player, one that will sleep until the player's turn and the other paying attention.

My question is: Should I work each player as a 'fork' and the threads on the fork, or just create some threads for the player and associate them somehow?

It's the first time I've worked with concurrency, semaphores and threads so I'm not sure about the good practices and programming style.

---

You've stumbled onto the edges of a huge religious war, revolving around the question

Should event-driven programs be written using multiple threads or using a single event loop?

The threads camp believes that individual entities, like "players", are more easily programmed when written as actual threads, possibly explcitly giving up the processor when they no longer need it. Information about the player's state can be stored in local variables and even in the program counter. But with threads you may have to worry about atomicity, deadlock, and the other joys of concurrent programming.

The event-driven camp believes that it's much simpler to get an entire application right when every entity is capable of responding to every event, and that entity gets total control of the processor for the amount of time it needs to process the event (which had better be finite, and usually had better be short). There are no worries about concurrency because every event handler executes atomically, but there is a programming cost: when the event handler finishes, all its procedures exit, and so information about its state has to be stored in the fields of an object allocated on the heap.

The threads story tends to shine when an entity has complex control flow or wants to use a lot of abstraction—both of these are hard to code without threads. The events story tends to shine when handlers are fairly simple—it's great having every handler execute atomically without having to worry about it, and it simplifies communication between entities.

Before proceeding with your assignment, find out to which religious group your instructor belongs.

Since you've asked about threads, I highly recommend the threads and channels libraries in Dave Hanson's C Interfaces and Implementations. The software is free, and the book is worth buying—it includes many other modules that will be incredibly useful to anyone writing homework assignments in C.

Should I work each player as a 'fork' and the threads on the fork, or just create some threads for the player and associate them somehow?

Unless you've been asked to use fork, I'd avoid it—the mechanisms for communicating between Unix processes are not that pleasant to use. If you can get the Hanson library, I'd say create a thread per player, and have the players communicate with each other (and with the game server, which should also be a thread) using Hanson's channels.

---

In a turn-based situation (game) you actually don't need threads, fibers/coroutines will do (better).

'Paying attention' does not require a thread, just access to the state (-changes) when you are ready to act again.