Programmer Musings

Another View of Human Multitasking

I've recently finished reading Joel Spolsky's Joel on Software in book form. In the book, I read the essay Human Task Switches Considered Harmful. As someone who has had a lot of experience with multitasking myself, and a fair amount with computer multitasking, I found this claim to be pretty amazing.

I have looked at Joel's claims pretty carefully and believe I see the difference between my experience and his. I suggest you read his arguments before continuing so that I don't accidentally misrepresent what he is saying.

The general gist of Joel's argument is that there are two major problems with multitasking:

• every time you do a task switch, there is overhead


• since neither task finishes early, the average time for completion is higher

These points are both true for computers as well. If we follow his logic for computers, we see that we should never use multitasking on a computer system either. Since we do. there must be some point where the logic breaks down. To my eyes, Joel's argument is a little simpler than the reality I live in. First of all, there are two major times when a system needs to task switch: after a defined time-slice and when blocking on a resource. Joel's analysis is based solely on pre-emptive time-slicing.

Any time a processing system performs a task switch because it ran to the end of its time-slice, we incur the cost of the task-switch overhead. On the other hand, if the task switch comes because we are blocking on a resource, the cost of the task switch is not as important because the current task cannot continue. Another task gets a chance to run sooner than it would have, so the overall time is reduced.

The main purpose for pre-emptive multitasking is to prevent one task from absorbing all available resources (cpu-time) and preventing other critical tasks from completing. This is obviously not the right model for a human, if completing tasks is highest priority. In this particular case, I agree with Joel completely.

This also explains why interruptions are so damaging to productivity. An interrupt forces a task-switch. You incur all of the overhead of changing state, just like in the time-slice case. In fact interrupts are worse for humans than for computers. If you know you will be changing tasks after lunch, you can generally aim for a good place to stop. With an interrupt, you have no choice of when it occurs.

On the other hand, I try to keep one major task and two or three minor tasks on my plate at all times. This way, when something causes me to block on the major task, (waiting on technical or business input, lack of some resource, a design problem that I just can't seem to beat right now) I can spend some time on the minor tasks. Every minor task I complete, is one more thing that actually gets finished. That way I don't spend the blocked time busy waiting (browsing the web, reading slashdot, etc.<grin/>)

Amusingly enough, one of Joel's counter-examples is the case where a project manager sets someone to work on three tasks because there is no way for the programmer to complete them all in the time allotted if he does them sequentially. This example is useful for two insights. The first is obvious, but people forget it in programming too. If you are processor-bound, more threads will not speed things up.

The second is more subtle. Even though it may not make sense from a technical viewpoint, it is sometimes more important to show progress than to complete more quickly. Most modern (general purpose) operating systems use pre-emptive multitasking. This is not to make things faster, which it generally will not do, but to make things more responsive. No matter how resource intensive the main task is, all other tasks get some time. Unfortunately, in business, sometimes it is more important to be moving forward than to complete.

It boils down to trade-offs, like everything else we do. If raw speed is what you need and there is no chance for blocking, Joel's suggestion of one task is definitely best. (Look at most embedded systems). If you have one major task, but there is some chance for blocking, adding a few low-priority tasks can help keep people busy. There is never a technically valid reason for a single person/processor to be scheduled for two or more critical tasks. Although there may be non-technical reasons (business reasons, responsiveness, etc.).

Unfortunately, many people latch on to multitasking just like programmers who are trying multi-threading for the first time. Without being aware of the trade-offs, you can easily make an incredibly slow system.