多线程或带有线程的进程
我必须模拟一个游戏，每个玩家都有回合并且需要“注意”正在发生的事情。
到目前为止，我知道每个玩家需要两个线程，一个线程会休眠直到轮到玩家，另一个线程会注意。
我的问题是：我应该将每个玩家作为“叉子”和叉子上的线程，还是只是为玩家创建一些线程并以某种方式将它们关联起来？
这是我第一次使用并发、信号量和线程，因此我不确定良好的实践和编程风格。
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 each 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你无意中陷入了一场巨大的宗教战争的边缘，围绕着这个问题
线程阵营认为，像“玩家”这样的个体实体在编写为实际线程时更容易编程，当它们不再需要处理器时可能会明确放弃处理器。有关玩家状态的信息可以存储在局部变量中，甚至可以存储在程序计数器中。但对于线程，您可能不得不担心原子性、死锁以及并发编程的其他乐趣。
事件驱动阵营认为，当每个实体都能够响应每个事件，并且该实体在处理事件所需的时间内完全控制处理器时，让整个应用程序正确运行要简单得多（这最好是有限的，并且通常最好是简短的）。不用担心并发性，因为每个事件处理程序都是原子执行的，但是存在编程成本：当事件处理程序完成时，其所有过程都会退出，因此有关其状态的信息必须存储在分配给事件处理程序的对象的字段中。堆。
当实体具有复杂的控制流或想要使用大量抽象时，线程的故事往往会大放异彩——如果没有线程，这两种情况都很难编码。当处理程序相当简单时，事件故事往往会大放异彩 - 让每个处理程序以原子方式执行而无需担心它是很棒的，并且它简化了实体之间的通信。
在继续作业之前，查明您的导师属于哪个宗教团体。
既然您询问了线程，我强烈推荐 Dave Hanson 的 C 接口中的线程和通道库和实现。该软件是免费的，这本书也值得购买——它包含许多其他模块，这些模块对于任何用 C 语言编写作业的人来说都非常有用。
除非你被要求使用 fork，否则我会避免使用它——Unix 进程之间的通信机制不太好用。如果您可以获得 Hanson 库，我会说为每个玩家创建一个线程，并让玩家使用 Hanson 的通道相互通信（以及与游戏服务器，这也应该是一个线程）。 。
You've stumbled onto the edges of a huge religious war, revolving around the question
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.
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.