Data protection

In a single-processor system, the only case where data protection is required occurs during interrupt processing. Since an interrupt might appear at any time, if the kernel is working with data that could be accessed or modified during an interrupt service routine, that interrupt must be prevented or delayed until the data manipulation is finished. As soon as the kernel is done with that particular piece of data, it doesn't matter if it is interrupted , because there will no longer be any possible conflict. The standard method used by the UNIX kernel to protect data was to prevent interrupts during critical sections of code by increasing the priority level of the processor. This would delay recognition of the interrupt until the level was reduced again. If you examine kernel code, you will see many spl() calls; spl stands for set priority level and is a means of blocking out interrupts that might interfere with the current section of code and the data it is manipulating. Obviously, you don't want to block important interrupts for long, or you may find yourself losing data. Priority changes are done frequently around small sections of code to delay interrupt recognition for as short a time as possible. There are also priorities associated with interrupts, so you only need to set the CPU priority high enough to block out the service routine you are worried about.

This works fine for a single processor. However, when there are two CPUs in a system, issuing a call to set the priority level of one processor high, thus preventing it from receiving interrupts, will not affect the operation of the other processor at all, and the interrupt is likely to be recognized and handled by that CPU instead, which defeats the whole purpose of the spl() call. This requires a major change in approach and design in order to make a real multiprocessor system work.