Game multithreading

You might as well ask in what parts you should use OOP and what parts don't need it. It depends on a lot of things.

Games that are heavily dependent of CPU time for both graphics and physics/logic/AI/etc. will benefit from having a dedicated graphics thread that draws objects at positions and states specified in one buffer while the positions for the next frame are calculated into another buffer. When both are done, the graphics thread can operate on the buffer the physics thread just updated, and the physics thread will updated the other.

I don't know too much about other techniques, but i consider this a minimal one. You can also just thread specific procedures if they lend themselves to parallelism.

Tell us more about what you're doing and we can give more specific advice. If you're going to ask a question this generic, might as well just google it instead.

Thanks for the advice!

You probably don't need to use threads. Doing so could make your game very buggy and hard to develop, while adding very little in value. Unless you are using this game as a way to learn complex multi-threading, I would advise that you build your game without threads. The majority of 2D games are not processor intensive enough to justify the additional work involved.

Definately don't go into threads, until you really have to or really want to (experimenting?). It's an absolute nightmare to debug and although as such they don't just "introduce" bugs, they do have a tendency to result in a less predictable behviour than fully sequential code, making it really hard to trap bugs. However, if you get to a stage where you are producing a major game, especially for consoles, it's essential to divide work into threads. Most common division is to dedicate an independent thread to specific subsystems, including game logic, ai/scripts, graphics, physics, audio and networking. This way you might still encounter synchronisation issues, but it's possible to effectively maintain and debug each of the systems individually.

Multi-threading is pretty complex and you'll probably find you'll spend all your time trying to debug the threading and not making progress on the actual game. Much better to have a finished single threaded game. Especially for a 2D game, it's doubtful you'd be pushing the cpu hard enough that you need multithreading.

If your goal is to actually learn multi-threading, and are prepared for the pain, the parts that are typically split into separate threads are things like user input, rendering, physics, loading data from disk and possibly the sound system. You'll want to identify which parts of the code don't rely on each other too much and can be run concurrently.

Almost certainly won't be needed for your game, but it all depends on what you want to do with your game.

If you're looking to learn or practice multi-threading, there are many other good ways to do it. Writing a multi-threaded search/sort would probably be good practice, and you wouldn't have to wrestle with unruly game code at the same time.

Like everybody else said, you probably don't want multithreading at all. Unless your goal is to learn about multithreading.

In any case, I would advise against multiple threads in favor of multiple tasks.
The difference being that threads are pretty heavyweight and coarse-grained constructs that are slow to create, destroy and switch between. Also, when using threads, it will be hard to scale to make use of all available cores. Example, if you have two threads, one for rendering and one for logic, then the game will run slower on a single core processor than a single threaded game would and would only ever make use of two cores, even on processors with four or more cores available.
If, instead, you process with tasks, which are basically chunks of code which can be run in parallel (and are more fine-grained than threads - eg, your rendering code may consist of multiple tasks, your logic may consist of lots of tasks), then they would simply be executed sequentially on a single core machine (it would still have overhead, but less than with threads), half could run in one thread and the other half in a second thread on a dual core machine, four threads on a quad core machine etc etc.

Now, instead of thinking about parallel processing in terms of "what module do I run in another thread", you think of your code in terms of "what sub-parts of each module can be run at the same time" and then you split these into their own tasks. Take a look at the forum threads linked below for more details.

Finally, I wouldn't recommend that you write your own task system - this is very difficult to do well - instead use an existing task-based library. My favorite is Intel Threading Building Blocks (if you use C++).

Some recent gamedev.net threads for you to read:

• Multithreading In Games
• ~ threads ~
• Threading in Games
• Multitreading, what to and what not to thread?

How about something simple as OpenMP?
Its complexity is at a minimum, don't get the full juice you would from doing it the hard way, yet get a lot for the little amount of effort put into it.

If you want something code free of licensing, you can check out my little threading implementation at http://nolimitsdesigns.com/game-design/threading-library/

It is only two files, requires no lib builds, free for any use and it is simple.

If you want something code free of licensing, you can check out my little threading implementation at http://nolimitsdesig...eading-library/

It is only two files, requires no lib builds, free for any use and it is simple.

If someone needs basic task support and parallel for, then this library might be a decent choice.

If you need something more full-featured, I would recommend Intel TBB. Ok, it requires a dll/so for most cases, but it is also free to use (in both commercial and non-commercial code). TBB also has parallel_for, parallel_reduce, parallel_sort, parallel_while and pipeline algorithms, as well as a bunch of concurrent containers (vector, queue and map), locking primitives, atomic operations, portable and thread-safe timing and a rich and full-features task API (with child tasks, task recycling and continuation tasks), which also does work-stealing and tries hard to be cache friendly. It also plays nice with other multithreading libraries, should you need or want to mix them.

I have no experience with OpenMP, besides what is covered by this book (though I have not tried it for myself). OpenMP seems like a good choice too. You could also look at FastFlow for a TBB alternative, though I have not tried it.

It all depends on what you want to use your threads for. I think you should do a bit of background research about threads and it will become clear how you should use them. For instance, one thing I am using them for is that I have a very large terrain that is not built entirely at run-time, so I build it in a background thread as the player moves around. Instead of using all these open source thread libraries, I just use thread calling with these: http://msdn.microsof...b(v=vs.80).aspx

They're windows only but that is my target platform

It all depends on what you want to use your threads for. I think you should do a bit of background research about threads and it will become clear how you should use them. For instance, one thing I am using them for is that I have a very large terrain that is not built entirely at run-time, so I build it in a background thread as the player moves around. Instead of using all these open source thread libraries, I just use thread calling with these: http://msdn.microsof...b(v=vs.80).aspx

They're windows only but that is my target platform

If that suits your needs, thats fine, but that is really a very low level way of handling multicore programming. It does little to help you overcome the pains of multicore: scaling (ie making use of more cores as they become available in newer hardware without having to reconfigure or recompile your program), efficient cache usage, load balancing work between cores, avoiding flase sharing, efficient and safe synchronization etc etc. Multithreading can be quite difficult and complicated and these higher level libraries (eg, task based systems) are designed to address these issues. Having said that, if you just need a background thread or two to prevent your main code from being blocked or have a few simple tasks you wish to run in parallel, these libraries are probably overkill. Once you want to do something more complex though, I'd recommend something like TBB. Note that TBB doesn't make windows threads, pthreads, boost threads etc obsolete as TBB is designed for performance and not asynchronous tasks - so you still may want to use these too.

You are right, though - the OP needs to do some research and find out what his needs are before diving in. Still, I think he can't go wrong with TBB.

As for "all these open source libraries", what do you mean by that? OpenMP has corporate backing. TBB is developed by Intel and was proprietary for a few years before they open sourced it and you can still get non-GPL commercial versions with commercial support contracts if you need.

You are right, though - the OP needs to do some research and find out what his needs are before diving in. Still, I think he can't go wrong with TBB.

As for "all these open source libraries", what do you mean by that? OpenMP has corporate backing. TBB is developed by Intel and was proprietary for a few years before they open sourced it and you can still get non-GPL commercial versions with commercial support contracts if you need.

Nothing wrong with those libraries, they just might be overkill depending on what someone is doing.

Just chiming in to restate that the "thread per subsystem" (render, logic, audio, etc) idiom is bullshit; "tasks" are indeed the application level abstraction you want, on top of a solid third party library to handle the task distribution to "threads".

Better still, don't parallelise a simple game speculatively.

Just because a game is 2D doesn't mean it can't use MT especially for things like AI.

There's two main uses for multithreading. One is to make things go more faster which is what many people tend to fixate on, but making for responsive asynchronous actions can be much more important.

For example if all your AI is done on a frame by frame basis it leads to lots of problems and can make for lots of wasted computing power. There's lots of stuff that just doesn't fit well with working frame to frame, and I'm convinced a lot of the reason so many games such so much is they are artificially shoehorned into this paradigm. Having to update something expensive every time you move the mouse can also kill responsiveness.

For making things faster, on the other hand, you generally want some kind of job queue. The big problem when it comes to speed is linear dependency, that is the fact some things depend on the result of other things before they can be calculated. That's the biggest reason it doesn't work out well to have lots of separate threads running, like a render thread or whatever. However if you design a job system well you can ensure that jobs are executed in proper order and that you pretty much never have completely wasted time where your main thread is just waiting on results.

You can use lots of libraries but when it comes to OpenMP I strongly recommend against it. The issue here is that the real difficulty in multithreaded programming is in breaking tasks up into a form that can be multithreaded. If you can do that multithreading is generally easy anyway. If you can't and if you don't understand the basics then you are going to get all the bad and none of the good. Since most of it is based on waiting and sometimes creates new threads, and due to the dumb comments the guy at intel makes, I'd say it's just a completely incompetent implementation of MT to be honest.

There's lots of stuff that just doesn't fit well with working frame to frame, and I'm convinced a lot of the reason so many games such so much is they are artificially shoehorned into this paradigm. Having to update something expensive every time you move the mouse can also kill responsiveness.

Threads don't solve this problem. On non-real-time OS, they might make it even worse since individual threads have absolutely zero guarantee of progress. For single-threaded versions there is either multiplexing or cooperative threading, which achieves same effect but without relying on external OS scheduler.

Multi-threading is just a very specific and very limited technological solution for solving concurrency and parallelism.

However if you design a job system well you can ensure that jobs are executed in proper order and that you pretty much never have completely wasted time where your main thread is just waiting on results.[/quote]
Unfortunately, job scheduling is an incredibly hard problem. While it's somewhat solved theoretically, linux kernel scheduler wars show that when it comes to user experience, it comes down to a lot of tiny details.

OS thread scheduler is a job queue, after all. GPU is out-of-thread as well, meaning any kind of graphics operation, even if drawing on desktop runs in separate "thread".

You can use lots of libraries but when it comes to OpenMP I strongly recommend against it.[/quote]
None of the libraries solve the design problem. They just provide mechanism to implement it. OMP, TBB, etc... are all the same in this regard. They are just a tool, like IDE. Having one may help, but it won't write the code.


Fortunately, hardware today is fast enough to absorb even absurd inefficiencies (Flash anyone), so one way or another, it doesn't matter. Even if using multiple threads adds a factor of 10 overhead, most of the time simply won't matter.