Jump to content
  • Advertisement
Sign in to follow this  
LancerSolurus

What do you thread?

This topic is 2785 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Since I recently had to delve back into threading for my game, I was curious as to what areas you use threading for?

I already know the most important parts I have to convert to threads in my game, this is just to see if maybe there might be other relevant areas I may have not thought of...

Share this post


Link to post
Share on other sites
Advertisement
All file operations - so I can use the main thread to render an animated loading screen, or stream in the next level whilst playing the current one.

Share this post


Link to post
Share on other sites
Multiprocessing requires additional design and introduces complexity that is generally avoided in games.


Many times you can use threading with no significant work. Most I/O calls offer asynchronous versions. (I/O includes everything from graphics to audio to file system access.) This type of threading requires very little work on your end if you can do other things while waiting for it to complete. You will need to either query or handle a callback, but that is minimal effort for the huge benefit.

There are some fire-and-forget tasks you can do in C++, such as freeing up resources and assorted garbage collection. Other languages take care of this as a background task, and it is something you don't normally need to block on before it completes.

You can often break out time consuming tasks into their own threads, as was pointed out earlier. It requires some design work to make sure you don't corrupt your data, deadlock, or cause other problems. These can generally be placed in a lockless queue by the main game threads, processed and removed by a worker, and then added to a "done" queue when processing is complete. These tasks can include pathfinding, physics processing, and other tasks.

Those are the most common forms that you will encounter.


More complex forms require significantly more work.

Sometimes you can get great benefits from parallel processing algorithms; searching is the best example as it can give superscalar results. Master/Slave processing for trivially parallalizable functions and thread pools can work for you if you have a bunch of tasks with unknown duration and want to load balance on multi-core machines. Sometimes you can use it for parallel effects processing.

But they require more work to keep the processing thread safe to prevent data corruption, race conditions, and deadlocks, and other problems.

Finally, there are whole classes of parallel processing algorithms, as opposed to serial processing algorithms that are most often used. Generally they don't apply to interactive game processing today, instead focused on offline processing of large data sets. They are typically covered in the last years of undergraduate school and more in depth during graduate school. You generally won't see this type of thing in mainstream games, but expect it to change in the future.

Share this post


Link to post
Share on other sites
Animation, AI, view culling, displaylist preparations, particles, physics, file IO (and decompression), sound. There are tonnes of things in a game, that with proper design are quite parallel.

And I don't mean putting Animation in its own thread. Instead I mean breaking up animation by skeleton and droping all the animations into a thread pool to split the work up. Same with almost everything in my list. Games have tonnes of objects running around, and updating them all in parallel at different stages of the engine gives you some large gains.

Share this post


Link to post
Share on other sites
In short my plan is to do 'everything'.

Although to say I'm using threads would be slightly wrong as I'll be using tasks with the aforementioned Threading Building Blocks library so I constantly have N threads spinning over M tasks.

As I'll be targetting DX11 only threading becomes a 'no brainer' with graphics and I've spent some time of late figuring out how integrate IOCP with a task based system so that loading of data can be fired off and picked up X frames later when ready.

In short; forget about threads.
Thinking in tasks is the way forward [grin]

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
In short my plan is to do 'everything'.

[...]

In short; forget about threads.
Thinking in tasks is the way forward [grin]


+1.

Share this post


Link to post
Share on other sites
I have been considering using OpenMP for doing the thread work. As far as the difference between tasks and threads, I'm not getting your meaning. To me threads=tasks since I threaded the entire function, in this case my entire Ogg audio sub-system.

As for file I/O, in some cases I could do that but since it is a portal based system, I can't preload the next system until the player chooses to go there.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!