Threading in Games

Just a quick note, I heard that putting your data loading in a separate thread from the game thread and streaming content from your data files can lower load times for a game. I personally think this would be quite tricky and could be a dangerous practise if done incorrectly (could cause potentially fatal errors if trying to use data which has not finished loading in the other thread yet).

After googling "STL thread-safe" I found articles stating that the Standard Template Library in C++ is not strictly thread-safe. Are you sure you want to develop in C++? It doesn't seem to be suited to multitheading very well. If so you might consider that there are portable threads available in the SDL APIs. If not Java and Python have an edge over C++ in terms of being able to do threading but both use bytecodes instead of native binary. I suppose it's possible to be very careful when using C++...

Quote:

Original post by Cacks 1. What would be the best multi-platform threading approach? I'd like my code to be as portable as possible. Would I just use OS specific preprocessor directives to include the appropriate implementations? This is how I am currently proposing to implement my threads at the moment.

There are object orientated cross platform threading libraries out there you can use, such as boost.threads.

Quote:

2. What elements of my game could I thread? I've been thinking about this & the main candidate for threading would be AI. Are there any other sub-systems that would be good candidates to thread? Using threads for sub-systems would give rise to synchronization problems though? 2b. Will the main performance increase come from threading at the algorithm level? E.g. using 2 separate threads for calculating weights of 2 branches of a tree? If this is the case then programming games will be very difficult as the game world would become a shared resource & I would have to use monitors? They are hard to implement & hard to debug.

Typically things that can be done in the background are good candidates for running in separate threads. Things like streaming resources for example. This is probably going to change when programming specifically for the next generation consoles however. To get the full power of the massively parallel Cell cpu for example, threading will have to be used in different ways and ways that may not be efficient on desktop machines. The Cell has 8 cores you want to keep busy at all times, so threading at the algorithm level in the way you suggested is probably most effective. Desktop cpus are not going to have 8 cores for a long time, and splitting game code into 8 threads vying for cpu time will hurt performance. Different threading strategies will have to be adopted for different gaming platforms.

Hi samuraicrow,

I want to develop for both Java & C++. But at the moment I'm concentrating on C++. I want to make my renders in OpenGL so C++ is the way to go. I know there are OpenGL bindings for Java. I'll be looking into that ASAP. But I want to get my C++ skills in order first.

Thanks for your suggestions!

The SC++L may not be strictly thread-safe, but C++ is still the language of choice for most multithreading applications today. (Just look at GNU/Linux.)

In answer to Cacks:

1. I would highly recommend boost::threads for your multi-platform threading. It's tried and true and a large number of others here at GameDev will recommend it to you also.

1b. I can't speak to this myself from experience, but I've heard that unmanaged C++ gets a pretty noticeable slowdown when mixed with managed.

2. There are many elements of your game engine that you could thread, but I would actually recommend conservativeness in that area, because more threads can incur a performace cut on the system and the game overall, as well as being exponentially more difficult to debug. In practice, many games and engines end up with about 3 total threads -- the main thread, which handles all the updating and rendering, a "timer" thread which handles callbacks and time-related messages and events, and a "loader" thread which spools data from files as necessary. Data loading is the most common use of a separate thread in games.

2b. Probably not. This would as you observed be quite difficult to implement, and even then would not in most cases gain you much of an increase. Most performance increases through threads are not "performance increases" per se, but a way of processing data concurrently such that when you need it, it's ready and when you don't or it isn't, you can continue with other tasks. Threads tend to be more useful at a functional level, where you interface with the rest of the computer's hardware (such as the hard drive or the graphics card).

Hope this helps,
Twilight Dragon

Quote:

Original post by Cacks 2. What elements of my game could I thread?

I have threaded my scene graph update. This means that transformation controllers, material propigation, bounding volume computation, and skinning occur in parallel. Async I/O also occurs in a seperate thread.