The joys of being good at multithreading

So, even though I’ve never taken any coursework on the subject, it turns out that I’m actually fairly good at writing multithreaded software. I’ve even managed to avoid a lot of the usual stupid code deadlocks that prompt people to suggest that multithreaded programming is inherently hard.

The thing is, most software isn’t. ZoomBrowser, which is what I’m currently using to manage pictures, isn’t fully multithreaded. Firefox isn’t (which often means that my wife’s login will have one Firefox process sucking up 50% of the machine and my login will have another Firefox process sucking up the other 50%). My scanning software isn’t.

So I’ve gotten used to these poorly multithreaded programs… which are going to be dog slow on 64 core desktops… letting me do other things while they crunched. And so when my fully multithreaded tool is crunching, suddenly I can’t do two things at once. And that starts to bug me, because I’ve gotten used to software that doesn’t suck up all of the CPU when I’m not using it. Clearly, it’s desirable for an application running on a user’s machine to not suck up all of the CPU, but to throttle back under some circumstances.

My current heuristic is simple. When the program is minimized, it will cut back on the amount of background processing that it does because it assumes that you are working on other things. I’ll probably work more on it later.