Multithreading in a computer game

[crexalbo]

I'm just looking for a sanity check concerning my use of multi-threading, and ideas as to how to improve / change it to make it more efficient. The main toolkits i am using are Allegro and PortAudio.

My primary thread initializes all necessary objects, then spawns two additional threads. The first thread it spawns is the engine thread, which translates all user input into player movement / options / etc. and performs any necessary calculations. The second thread spawned is the render thread, which will turn the game's internal state into something the user can understand and display that image in the window. The main thread, after spawning these two threads, attaches itself to the keyboard and mouse and waits for user input.

The main thread mutates an object in memory that represents the state of the keyboard/mouse at any given instant in time. The engine thread then accesses that state every tick and incorporates the user input into its calculations while it mutates the internal game state. The render thread runs as fast as it can to continually take snapshots of the game's state and display it on screen. I ensure that all interactions with this data are thread-safe (i use mutexes).

[Disch]

The benefits of multithreading deteriorate rapidly when you need to sync between threads very often. The more you do this... the more likely you're going to have a thread waiting for another thread to finish its business.

It sounds like you are having one thread update the logic, and another thread doing the rendering. This is probably not ideal, as the rendering code will need to poll camera/player positions (and thus will need to lock them)... whereas the game logic will need to update those positions (and thus will also need to lock them).

So it's almost a certainty that one of your threads will be waiting on the other one at any given time. Which probably means that having 2 threads in this case will be slower than having one thread (in addition to being more complicated and much more bug prone).


Multithreading in a game is tricky because game logic is linear in nature. I've personally found the best use for additional threads to be to "get things ready" for the main thread to use eventually (but that it doesn't need right now)... like prep/load resources in the background.

[crexalbo]

I have noticed that problem, both in theory and in practice. So should i do everything in one thread, or have a separate thread for user input?

[Disch]

So should i do everything in one thread, or have a separate thread for user input?

Well the question is... what do you hope to gain by having user input in another thread?

Assuming you're trying to improve speed... you have to ask yourself how effective that would really be. Does processing user input really take so much time that you want it to run in parallel?

Processing user input (in my experience) is usually pretty fast. It's probably faster than the slowdown caused by syncing threads.



So no, I would not recommend a separate thread for user input.

[crexalbo]

So i made a beautifully complicated multithreaded environment for nothing haha Thank you!