[cs631apue] kernel vs process

[Jan Schaumann]

Kashi Vishwanath Bondugula <kbondugu at stevens.edu> wrote:

> I have gone through what you have said and the O'Reilly material, I have one small doubt for single processor systems where only one process can run at a time, as you have mentioned kernel once it boots up it doesn't really do anything but it has to run components like scheduling processes, handling interrupts etc. for which the kernel has to be running on the CPU right?

Not quite.  The kernel does not need to be running
actively on the CPU to ensure processes are scheduled
and preempted.  It initiates the scheduler, which,
when a new process is created, provides the
execution context, which includes its maximum CPU time
allotment.  (The kernel only runs anything when it is
entered e.g., via a syscall or an interrupt.)

During process execution, a timer goes off every so
often causing an interrupt and switching context to
the kernel, where the scheduler can then juggle
whatever priorities it has to consider and either
continue the same process or give priority to a
different process.  After it has done that, the CPU
context-switches to the userland process again,
restoring the process's saved state from its CPU
contexts.


> How are interrupts handled?? Maybe this is going a bit out of context, but I am trying to understand at a given moment on the CPU how can both kernel and process under execution are running because the kernel must shift the process to user mode and kernel mode based on the code right?

At that time when the user process is running on the
CPU, the kernel is not actively running.  The periodic
interrupt or preemption is due to the scheduler having
allocated the resources for the given process only for
a short duration; it does not need to be running at
the same time.  That is, the process is not taken off
the CPU by the running scheduler, but is evicted from
the CPU due to the time limits imposed on the process
at the time it was placed on the CPU.

> And what do you exactly mean by kernel runs on between user processes??

Maybe try to think of the kernel as the 'main'
function of a program, and user processes as
individual functions called from 'main'.

main() {
	funcA();
	do stuff here;
	funcB();
}

The kernel creates a new process (calls funcA), that
process now executes (we're now in funcA), and the
kernel is not doing anything; when the process
terminates (funcA returns), we're back in the kernel
and can do stuff there before we create another
process (call funcB).

Process eviction during preemption could then be seen
as similar to what happens when a signal occurs during
the execution of funcA: control is transferred out of
funcA, but after the signal handler completes, you are
returned into funcA where you left off.

Not sure if this analogy only makes things more
confusing, but I hope not.

-Jan