Suspend/Resume? You are doing it wrong™.

So you need help with Suspend and Resume?

The following is the full text of an answer I gave recently to a question on StackOverflow. This and some other very related questions pop up regularly on all channels, not only on SO, where number of questions containing suspend and resume is at 2.230 at the time of writing. I personally stopped counting how often I have seen or heard that kind of question long ago.

To me questions like the following show a lack of understanding of even the most basic concepts of parallel/concurrent programming in general, and multithreading in particular. I have to admit, at least to some extent, this is somewhat frightening to me. There are so many programmers out there, living each and every day in an highly asynchronous, parallel and concurrent real world called life without having much problems with it (well, for the most part), but still struggle with parallelism, asynchronous and concurrent programming concepts in magnitudes when it comes to programming and/or software engineering.

My application has to suspend and resume a different process every few microsecs. It works fine only sometimes it feels like it suspends the process for non-uniforms times. I use the win API: ResumeThread and SuspendThread.

Is there a way to sleep some particular thread from another thread?

Help needed with suspending and resuming multiple threads ...

I just noticed that Suspend() and Resume() [...] have been deprecated. What is the workaround for this? Is there a better than Suspend/Resume way to pause a thread when it is not needed?

Original answer

The single best advice I can give with regard to Suspend() and Resume(): Don't use it. You are doing it wrong™.

Whenever you feel a temptation to use Suspend() and Resume() pairs to control your threads, you should step back immediately and ask yourself, what you are doing here. I understand, that programmers tend to think of the execution of code paths as of something that must be controlled, like some dumb zombie worker that needs permament command and control. That's probably a function of the stuff learned about computers in school and university: Computers do only what you tell them.

Ladies and Gentlemen, here's the bad news: If you are doing it that way, this is called "micro management", and some even would call it "control freak thinking".

Instead, I would strongly encorage you to think about it in a different way. Try to think of your threads as intelligent entities, that do no harm and the only thing they want is to be fed with enough work. They just need a little guidance, that's all. You may place a container full of work just in front of them (work task queue) and have them pulling the tasks from that container themselves, as soon as the finished their previous task. When the container is empty, all tasks are processed and there's nothing left to do, they are allowed to fall asleep and WaitFor(alarm) which will be signaled whenever new tasks arrive.

So instead of command-and-controlling a herd of dumb zombie slaves that can't do anything right without you cracking the whip behind them, you deliberately guide a team of intelligent co-workers and just let it happen. That's the way a scalable architecture is built. You don't have to be a control freak, just have a little faith in your own code.

Of course, as always, there are exceptions to that rule. But there aren't that many, and I would recommend to start with the work hypothesis, that your code is probably the rule, rather than the exception.

---