= Solution
First, suppressing <kernel preemption> simplifies protection of shared kernel data on a uniprocessor: another ordinary kernel execution cannot be scheduled in the middle of a short update which temporarily breaks an invariant. Fewer paths require preemption-specific locking and reentrancy handling, making the <operating-system kernel> easier to implement correctly.
Second, it avoids involuntary kernel <context switches> and their scheduler, register-save and cache-disruption costs, and can make the execution of short kernel operations more predictable. The tradeoff is greater scheduling latency if a kernel operation runs too long. \b[Simpler synchronization and lower switching overhead are the two reasons.] Non-preemptive kernel code can still receive <interrupts> or block voluntarily, and multiprocessor execution still requires synchronization; non-preemption is not a substitute for all locking.
Back to article page
