For some time, I've been a little uneasy with Dale Emery's article on [http://www.dhemery.com/cwd/2005/11/multitasking.html Multitasking and Conflict], not because what he says is wrong, but because I don't believe it tells the whole story. Don Gray's [http://www.donaldegray.com/blog/archives/03-01-2006_03-31-2006.html#50 critique] of Johanna Rothman's article on [http://www.ayeconference.com/Articles/ContextSwitching.html Context Switching] was the trigger to write up a few of my own thoughts.

You see, I greatly respect all three of these people, and I agree with what they all say. But there's more to it than that. This article is not yet finished, but I wanted to capture some current insights.

I started in software development writing code for 8-bit microprocessors. Most processors support what's called an interrupt which triggers a context switch and is used to support multitasking. In the simplest cases, interrupts come from external hardware wired to a port of the microprocessor, but later, more sophisticated processors added the software interrupt where the trigger can be from some code running on the microprocessor.

When an interrupt occurs, the processor pushes the contents of the registers (small bits of special purpose memory within the processor), including the one that points to the next instruction to be executed, onto the stack. It then starts executing code at a location appropriate for that particular interrupt until it encounters a "Return From Interrupt" instruction. This instruction marks the end of the interrupt service routine and the processor pops the register contents off the stack back into the registers and resumes operation as if nothing had happened.

This is a very efficient and deterministic process. People, unfortunately, can have a little more trouble making such a context switch and then switching back. What can go wrong? As [http://www.donaldegray.com/blog/archives/03-01-2006_03-31-2006.html#51 Don says],

I think he's absolutely right about the context switch back, but that he underplays the context switch out. I've been interrupted while in deep concentration and, while I turned to answer the interruption, was unable to let go of the previous context enough to concentrate on the new context. I was able to let go of the previous context enough to lose that thread of thought, however. This is the worst of all possible worlds. Not only have I paid the price of being interrupted, but the interruption didn't achieve anything positive.

And Don doesn't even mention the hysteresis that we humans exhibit. After we finish the "game of trying to find where we were, why we were there, and what we were doing," we're not really in the place where we were. Like a piece of metal that been bent, and bent back, we are not unchanged by the process. The place we find to resume our previous context may be an OK place for making progress. In rare cases it may even be better than where we were. Most of the time, though, we've lost some subtle insights that had not yet been expressed in words (or code). We've lost the flow.

Sometimes it's very important that a process not be interrupted in a critical section of code. To prevent this, an interrupt mask is used to mask off, or disable, interrupts. When the mask is turned off, and interrupts reenabled, then an interrupt that occurred during the critical section will be notices and serviced.

For people, such a critical section might be a period of time where they get into the [http://en.wikipedia.org/wiki/Flow_(psychology) flow] of creative work. How can they mask interrupts while in this state? Well, like a microprocessor, it's important to mask them before entering this state. Perhaps by closing the office door before starting the work as a signal that you're not to be disturbed. Perhaps by teaching others to recognize the signs that you're in a critical section, and not to disturb you during those times. I'd love to hear your ideas on masking interrupts.

It's generally a good idea to reenable the interrupts in a reasonably short time so that important things aren't delayed too long. (If they weren't important, they probably shouldn't be assigned to interrupts.) In a processor, if interrupts aren't re-enabled, things just don't get done. People are more resilient, though, and will re-enable interrupts on their own if feel it's important. If your office door is always closed, some people will cease to take it as a sign that you shouldn't be interrupted. You will have lost control of your interrupts, again. People will interrupt you for low-priority things, but also some high-priority things just won't get done. Not everyone has the same threshold of when the interrupt mask should be ignored.

Sometimes the interrupting task is so important that you don't care if you interrupt even a critical section. For this, you use the non-maskable interrupt. As it's name implies, the interrupt mask doesn't affect it. The non-maskable interrupt may be used for things like a reset button.

What if the building catches on fire? You'd want to be notified, even if you had your door closed and were working on something very creative and important. Survival trumps creativity. This is a non-maskable interrupt.

The first processors tended to have only a single interrupt. For simple things, this might be enough, but people eventually developed more sophisticated designs to service more sophisticated needs. A typical implementation supports multiple interrupts with multiple interrupt priorities. As a general rule, a lower priority interrupt may not interrupt the execution of a higher priority interrupt. This is accomplished by automatically setting the interrupt mask to that level, masking lower priority interrupts but not higher priority ones. The interrupt service routine may, however, unmask lower priority interrupts after it has finished the most important part of its work. Or, it may mask all interrupts while it accomplishes a critical task.

ToBeWritten: How might people employ such flexibility.

ToBeWritten: ContextSwitching from the point of view of the interrupter. How is this different when the interrupter is a subordinate of the interruptee? a peer? a manager?