Keep in mind, unless threads are used for a -good- reason they are a total waste and if anything, could lower performance.

That said, for anything that can run asynchronously really where the main thread doesn't need to stop and wait for it, definitely a performance boon.

Threading isn't exactly some mystical art it just requires preparation and proper areas to use it in. For some languages there is a lot more built in support for threading as well.

i, I'm learning how to create threads on SDL and at Qt on the same time and my question is connected with it. Is there are real application for multi-threading in games, especially in nowadays games, are multiple threads used often in game development? And can you give me some examples for using this technique in games creation? Thank you

I just want to start off by saying that multi-threading is a complex subject, and you can be in for a world of hurt if you try to use it in a game without knowing what you're doing.

That said, yes there are a lot of uses in games and any serious game engine will use it. To what extend it gets used is more a question of whether the engine was built with threading in mind or added in afterwards. Adding multi-threading as an afterthought can be messy and buggy and hard to do, and it will only give you limited benefits.

Things that can be, and often are, threaded in games:

• asset loading
• rendering
• game logic and scripting
• physics
• networking
• UI
• Loading/Wait screens

So, basically, everything in a game can be threaded. It can be through hard-coded threads (rendering thread, logic/update thread, loading thread, UI thread) or through a job manager where you break up tasks into separate blocks that can be handed off to a system. This system then has "worker" threads which handle the jobs in their own time. The responsibility of the game in such a system is really just to create jobs that it can feed to the job manager.

Most game engines use hard-coded threads, because they're relatively easy to code and can work readily with existing code that wasnt originally built for threading. This however has it's limits because it doesnt scale well as more cores, and hence worker threads, become available. It's also normal that this type of system will not be able to fully use all the available CPU time due to some threads having to wait for others.

Few engines use the job manager/scheduler type systems, but they are in theory superior, if harder to architect. Such a system can be made to more fully utilize the available CPU resources, but this depends on how well the jobs can be made independent of each other. It also scales well with more cores/threads, since the distribution of what's threaded isnt hard-coded.

Despite using C++ and C# together, I depend heavily on C# to do the threading, so far this has been great and though I am not sure if this would be considered the 'best' approach, it works so nicely and so far without any issues.

Although somewhat .NET related, this article gives an ok idea of when to have a long running separate running thread instead of using the threadpool / parallel(TPL) in C#, I know you are using C++ but it still is a pretty decent read. I haven't even bothered reading anything to do with C++ threading, it is the one area in C++ I have just ignored completely lol so im not sure how things work with threading there.

My technique atm is focusing on the threadpool (async / await) / TPL / PLINQ etc in .NET, I am still yet to create my own long running thread in C# however, most of the scenarios just don't feel like they need their own personal long running thread, when multithreading is needed I take full advantage of the threadpool and http://msdn.microsoft.com/en-us/library/dd537608.aspx and I haven't really considered my update / render calls to be independent enough for them to have their own dedicated thread. For now I cant see any long term benefits in my apps for having a long running separate thread.

0r0d sums up the areas where I use multithreading, the only other area I would say I would use it in is sound manipulation but that isn't something I am even doing in a game.