1
$\begingroup$

Suppose a process does system call, hence it goes to kernel mode, the registers are saved. Now the system call will be running in process' allocated kernel stack.

  1. Can there be a context switch when a system call is processed?
  2. Is really the system call allocated process' kernel stack?
  3. If context switch is possible, this means kernel has set the timer for this. Right?
  4. Are system calls part of job scheduling(separately) or this are include in job scheduling of process?

I am really messed up with this kernel stack.

$\endgroup$
3
$\begingroup$

If the kernel decides to do a context switch, it's in response to some event which caused the processor to enter kernel mode. This can be either a system call or an interrupt (which can be a timer interrupt or some other interrupts).

Whether the kernel is processing an interrupt or a system call, there are good and bad times to do a context switch. The kernel does what it wants to do, and then at the end of the processing it decides which user thread to schedule next. If it decides to schedule a thread which wasn't the last scheduled thread, it then does a context switch.

During critical parts of the processing, the kernel may disable interrupts. If an interrupt happens while the kernel is already active and doesn't have interrupts disabled, what usually happens is that the kernel does what needs to be done immediately (for example, read data from a peripheral), and adds an element to a queue to remember what needs to be done later. In Linux, these are called the “top half” and “bottom half” of interrupt processing; I don't think there's a standard term even though the concept is common. For example, if a network interrupt is triggered while the kernel in the middle of communicating with a disk, the kernel reads the network packet and stores it into a queue; then, when the disk I/O is finished (or can be paused), the kernel processes the network packet, and at this point it may decide to schedule a task that has received some input from the network.

In case there's any doubt, a timer is not required for a context switch. A context switch can happen any time a system call is in progress. The connection between timers and context switches is that if user code never makes any system call, and there is no system event (user input, networking, etc.) that causes an interrupt, the only way a context switch can happen is if a timer interrupt causes the kernel to wake up. And there are operating systems that only have non-preemptive multitasking; such kernels don't set a timer interrupt, and only do a context switch during a system call.

$\endgroup$
2
  • $\begingroup$ you said context switch can happen while executing system call. that system call is executed in kernel stack of the process. Before executing the system call by trap handler, the registers of user's process' stack will be saved. Now, if there is context switch while executing system call, where will the registers be saved? As the user process registers are stored in trapframe in kernel stack. $\endgroup$ May 29 at 12:21
  • 1
    $\begingroup$ @DavidRoonie If the kernel has separate stacks for each process (which some kernels do, some don't), a context switch involves switching to a different kernel stack, not just a different user stack. $\endgroup$ May 29 at 22:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.