Pro's/Con's of separating game logic and render threads

Question

Originally, I have thought that it is good practice to separate my game logic (updating) from my rendering thread. In this threading model, the rendering thread has no limitation on frame rate and simply draws whatever information is currently made available by the updating thread. On the other hand, the updating thread is monitored, and has a capped frame rate.

I'm led to believe this is BAD and will lead to many coding struggles down the road...

So, I'm wondering what are the POTENTIAL benefits for separating updating from rendering? Likewise, what are the POTENTIAL benefits gained when keeping the updating and rendering in the same thread? What are the losses for each method?

Answer 1

In a word, synchronization. If you have some data (your world) which you're reading from one thread (the rendering thread), and writing to in another thread (the logic thread), it is possible that your data will be read in an inconsistent state (for example, half the world has been updated, but not the other half).

To maintain consistency, you will probably have to make sure no reading occurs while you're writing, which is functionally equivalent to doing both things on the same thread.

There are some tricks you can do. For example, have two copies of the world, and while you're reading from one, you write to the other one. This solves some problems, but creates a lot more. For example, your world will always be one frame behind the drawing. Also, you'll be using twice the memory, and you still have to do some synchronization to make sure you switch from one copy of the world to the other correctly.

Writing synchronized multithreaded code is extremely difficult. It always seems easy, but it always becomes much more complicated as you're writing it. Debugging it is also hell (speaking from firsthand experience).

Now, a much simpler, and probably more efficient multithreaded model is not specializing threads, but dividing work across several threads. Create a bunch of independent work items, and assign them to threads to be worked on. If the work items are independent, no complex synchronization is required, and this scales to as many threads as you wish.

Also, one of the most important things you can do to make more responsive games is to use asynchronous I/O. Don't block threads when reading or writing to disk/network. Those threads won't be doing anything else but waiting for I/O to end anyways, and you can still do other useful stuff with them. It requires rethinking a bit your resource loading, but in my experience, it is one of the things that can greatly improve performance and responsiveness in a game.

Besides, why do you want to draw as fast as you can? If you draw at more than 60fps, you will either have tearing, or the graphics adapter will cap you at the monitor's refresh rate. But even if you draw at 1000000 fps, if the world updates are choppy, the game will feel choppy.