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. ToBeWritten: What can go wrong.

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. It's generally a good idea to reenable the interrupts in a very short time so that important things aren't delayed too long. (If they weren't important, they probably wouldn't be assigned to interrupts.) 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 the reset button.

ToBeWritten: How people mask their interrupts. How this can go wrong, both in terms of failing to mask an interrupt or of masking what should be 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.

• [http://www.donaldegray.com/blog/archives/03-01-2006_03-31-2006.html#51 Don Gray's response]