Kernel threads do not generally get pre-empted. If an interrupt causes some higher priority user process to become runable, the current kernel doesn't switch to it until it's finished processing the request from the current process even though it's a lower priority request.
The "fully" vs "partially" is distinguishing between the switch-immediately approach, and the common alternative: adding calls to schedule() in the long kernel code path. This "partial" alternative is a hack which makes the kernel appear pre-emptive in those areas where it's known to matter, but determining the points is a manual process prone to error and it adds complexity to the kernel.
Neither description is precisely literal; they're just different points on the spectrum of responsiveness. A "fully preemptive" system still won't preempt atomic operations, and strictly speaking the "partial" form using schedule() calls to relinquishes the processor isn't preemption.
Regards,
Graham
Slashdot Mirror
Kernel threads do not generally get pre-empted. If an interrupt causes some higher priority user process to become runable, the current kernel doesn't switch to it until it's finished processing the request from the current process even though it's a lower priority request. The "fully" vs "partially" is distinguishing between the switch-immediately approach, and the common alternative: adding calls to schedule() in the long kernel code path. This "partial" alternative is a hack which makes the kernel appear pre-emptive in those areas where it's known to matter, but determining the points is a manual process prone to error and it adds complexity to the kernel. Neither description is precisely literal; they're just different points on the spectrum of responsiveness. A "fully preemptive" system still won't preempt atomic operations, and strictly speaking the "partial" form using schedule() calls to relinquishes the processor isn't preemption. Regards, Graham