Multithreading Madness?

I've been toying with the idea of multithreading in my games logic and I've come to an impass. I'm far from an expert on multithreaded programming (in fact, I'm a total novice) and I know that multithreading will not speed up my program only allow it to be more responsive but I've been wondering exactly what would be considered overkill?

I was thinking of having all of my in-game objects (entities) doing their logic in their own threads. However, there's the possibility for thousands of entities so would it make sense to create a new thread for every Entity? This seems like overkill and I can see it even slowing down the program and even possibly causing problems with the operating system.

So I suppose the question now is how can I do multithreading with my entities such that the program remains responsive (e.g., continuing to render frames even if the logic for all entities hasn't been completed). Would it make sense to through an update loop into a thread that simply iterates through a list of Entities telling them to perform their logic?

Well, the first thing to remember is that the two words "multithreading" and "madness" are quite often synonymous. Keeping that firmly in mind, you should ask yourself if there is some way to avoid it, if possible, using some other technique. You could, for example, have an update_entity function that is called in a loop to keep each entity going in a synchronous-like fashion. Of course, coming up with a system that works in that way has it's own unique challenges and limitations, so you may end up being forced to use threads, after all. In that case, having a good book on concurrency handy is always a good idea.

If you've got lots of dependent data (your objects are moved by one thread, and rendered by another), then threads are going to be a disaster waiting to happen.

By the time you've thrown in all the mutexes and semaphores to guarantee correct concurrent operation, the performance of the whole thing will suck.

A "render thread" and an "everything else" thread might make sense, particularly with multi-core machines becoming fairly common. But you still need your head screwed on to make a decent job of it.


If you thought debugging is hard now, just wait until you try to debug your first race condition.
Unusual software bug - Wikipedia, the free encyclopedia

Heh. Yeah, I've avoided multithreading as best as I could up until this point (needed to do it for my updater utility to have the download function working in a thread while the rest of the program continued to operate... it's still not completely totally 100% perfect but it does the job (had issues with race conditions then that I've since corrected.... *shudder*).

Anyway, the idea for me was to have the logic calculations of the entities running in their own thread to keep that stuff in the background while the rest of the program continued merrily along rendering away (graphics are totally separate from the logic itself).

Basically what I'm getting is that there's point to using multithreading in this case and I should just go with a straight-forward, more 'traditional' approach.

Rendering is a linear process. You cannot present until every object draws and you cannot move to the next update until the previous render finishes. This means even in a thread you will be waiting for every object to draw to the back buffer before you can update the next frame. As such I see no benefit in threading the rendering.

Good candidates for threads:
* AI
* Sound
* Input
* Network