What's a good way to distribute delayable tasks between frames to avoid lost frames?

Question

I'm having a problem with finding a good way to keep the framerate high and at the same time keep running methods of game world update. I figured I could just put those methods in a thread so they are executed simultaneously with the rest of the game loop methods, but the threads tend to hog resources, which causes lost frames.

Then I thought I should break down tasks in parts and only run a little piece of a bigger task each frame or so. But this turned out to be way much slower than expected, and it also took a lot of time to implement.

After thinking some more about threads I found another way to use them: Thread.Suspend and Thread.Resume methods ought to prevent threads from keeping hogging all the resources until the game drawn or calculates some physics. But I also read that it's risky because you can't know what the thread is doing right before you suspend it, which may cause big problems. My tasks are mostly independent from each other, but still, some of them rely on objects which are sometimes edited by two separate threads, and sticking those operations together is an undesired solution.

Are these options any good? What other solutions for this problem do you know?

Answer 1

Then I thought I should break down tasks in parts and only run a little piece of a bigger task each frame or so. But this turned out to be way much slower than expected, and it also took a lot of time to implement.

Did you profile to figure out why it was slower? Assuming it was the overhead of task management, there are two main possible problems: Picking too small a chunk of work for each individual 'task', or using a task management system with too much overhead for your purposes (e.g. using a web server job system meant to distribute tasks across multiple machines).

Job/Task systems come with some necessary overhead, but correctly implemented and fed appropriately sized chunks of work, the overhead should be relatively small. They're frequently used to improve performance by giving multiple threads relatively self contained chunks of work to do in a sane and consistent manner.

After thinking some more about threads I found another way to use them: Thread.Suspend and Thread.Resume

You can accomplish much the same effect with normal synchronization primitives (locks, semaphores, etc.) without the nasty downsides of blindly fiddling around with the thread run state can have. Aside from your own locks, there's also the locks used in implementing every single 3rd party library (right down to the underlying .NET framework, runtime, and even the debugger itself!) to worry about. If the thread that's supposed to resume the paused thread ever tries to lock the same mutex, your program is hosed.

Calling it risky is an understatement: It's basically guaranteeing your program will at some point deadlock. There's a reason it was immediately marked deprecated in the 2.0 version of the framework, and I'd be confident it's author regrets making it available in the first place.