57

I am sorry to ask this question when it has already been asked but I couldn't get a clarity from them. So I am asking the following related questions to get the difference between system call (mode-switch) and context switch

  • Why is it said that the system call doesn't require context switch when the context of the process making the call has to be saved and then reloaded. Is it just because according to the definition of context switch a switch has to be made to another process.

  • What does it mean that when a system call is made the kernel executes in "user context".

  • According to the wikipedia article : http://en.wikipedia.org/wiki/Context_switch

a context switch is not necessary for system call but it depends on the operating system and a context switch might occur during a system call. I am wondering what would happen in the case when the context switch takes place at the time of system call. Any examples?

red0ct
  • 4,840
  • 3
  • 17
  • 44
vjain27
  • 3,514
  • 9
  • 41
  • 60

2 Answers2

101

You need to understand that a thread/process context has multiple parts, one, directly associated with execution and is held in the CPU and certain system tables in memory that the CPU uses (e.g. page tables), and the other, which is needed for the OS, for bookkeeping (think of the various IDs, handles, special OS-specific permissions, network connections and such).

A full context switch would involve swapping both of these, the old current thread/process goes away for a while and the new current thread/process comes in for a while. That's the essence of thread/process scheduling.

Now, system calls are very different w.r.t. each other.

Consider something simple, for example, the system call for requesting the current date and time. The CPU switches from the user to kernel mode, preserving the user-mode register values, executes some kernel code to get the necessary data, stores it either in the memory or registers that the caller can access, restores the user-mode register values and returns. There's not much of context switch in here, only what's needed for the transition between the modes, user and kernel.

Consider now a system call that involves blocking of the caller until some event or availability of data. Manipulating mutexes and reading files would be examples of such system calls. In this case the kernel is forced to save the full context of the caller, mark it as blocked so the scheduler can't run it until that event or data arrives, and load the context of another ready thread/process, so it can run.

That's how system calls are related to context switches.

Kernel executing in the context of a user or a process means that whenever the kernel does work on behalf of a certain process or user it has to take into consideration that user's/process's context, e.g. the current process/thread/user ID, the current directory, locale, access permissions for various resources (e.g. files), all that stuff, that can be different between different processes/threads/users.

If processes have individual address spaces, the address spaces is also part of the process context. So, when the kernel needs to access memory of a process (to read/write file data or network packets), it has to have access to the process' address space, IOW, it has to be in its context (it doesn't mean, however, that the kernel has to load the full context just to access memory in a specific address space).

Is that helpful?

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • 4
    Awesome explanation! Thanks!! Definitely helpful :) – vjain27 Feb 11 '12 at 20:48
  • 1
    Thanks for the clarity. I have one thing still on my mind. If the upcoming process pages had been swapped out, then there will be also cost for swapping them (pages) into the memory, right? – stdout Apr 14 '17 at 14:08
  • @zgulser Naturally. – Alexey Frunze Apr 15 '17 at 08:13
  • I have one more question. During the mode switch, from user to kernel, some of the kernel code (interrupt handler) is executed as a result of software interrupt. So this means some part of the kernel code must be loaded onto memory as well right? – stdout Jul 16 '17 at 11:40
  • @zgulser Obviously. – Alexey Frunze Jul 16 '17 at 11:42
  • I think this happens not as much as "full-context switch". Moreover, this means all interrupt handler (including both hardware and software handlers, also the interrupt vector) code is in the kernel. – stdout Jul 16 '17 at 11:46
  • 1
    @zgulser If I'm not mistaken, in principle, on x86 you can have user-mode tasks to handle interrupts and exceptions (look up *task state segment* and *task gate*). Some other CPUs may support a similar scheme. However, the most common is to handle interrupts in the kernel entirely or partially (the system part). Anyway, if you have a question, make it a new one. If you want to discuss this stuff, there are alt.os.development and osdev.org. – Alexey Frunze Jul 16 '17 at 12:25
  • I will. Thanks for the input! – stdout Jul 17 '17 at 06:38
  • 1
    @AlexeyFrunze So there is no context switch in case of non blocking system calls right ? – Zephyr Dec 05 '17 at 14:10
  • 1
    @Zephyr There shouldn't be or it should be unrelated or transparent to the non-blocking system call. – Alexey Frunze Dec 10 '17 at 19:57
  • @AlexeyFrunze Thanks for replying. In non blocking call, is the mode changed back to user mode from kernel mode immediately after calling a privileged instruction so that user application can continue? If it is changed back to user mode then how can kernel process the non blocking system call as the mode bit is changed to user mode? I am bit confused. – Zephyr Dec 18 '17 at 15:20
  • @Zephyr If there's nothing else to do in the kernel and nothing to wait for, the system call completes and the user code resumes after the instruction that initiated the system call. Running user code in kernel mode is a bad idea generally and should never happen. – Alexey Frunze Dec 20 '17 at 10:16
  • @AlexeyFrunze What would happen in case of asynchronous IO ? User application can continue after requesting for IO so the mode should be changed to user mode immediately after the call so that user need not wait. If the mode is changed immediately before the kernel completely finishes the IO then how can kernel proceed further? If kernel first finishes the IO as you said then user has to wait for a long time for IO. – Zephyr Dec 20 '17 at 10:25
  • @Zephyr The asynchronous I/O request may be queued and eventually handled by a dedicated kernel thread or process (the latter is a typical arrangement for micro kernels). The completion may be signaled back by invoking a user-provided callback or by using a synchronization primitive which the user may wait on. Or the user may poll to find out whether the request is complete. You should not think of the kernel and drivers as a single active entity. While the user thread/process is resumed, there's something else that works on its behalf to complete the asynchronous request. – Alexey Frunze Dec 25 '17 at 06:49
  • Does this mean that system call can't be slower than context switch? – dae Dec 15 '20 at 11:55
  • @dae A system call can be much much slower than a context switch. Blocking inside of the system call on some I/O can be very (if not arbitrarily) long. – Alexey Frunze Dec 16 '20 at 06:45
  • @AlexeyFrunze Sorry, what I wonder is that does this mean the switching time of system call can't be slower than the switching time of context switch? – dae Dec 16 '20 at 06:54
  • @dae If you're focusing on a single instruction like x86's int/iret, syscall/sysret, sysenter/sysexit, it may be blazingly fast (int/iret are complex and may be slow, it depends on how you configure things). But that is kinda expected. If you're asking about something else, please elaborate. – Alexey Frunze Dec 16 '20 at 09:08
-6

mode switch occurs when a user only wants to access things which are only suitable to a kernel mode

dennis
  • 11
  • 12
    This reads like a mediocre comment, but not like an answer. Please spent some *serious* time when giving answers - instead of dumping a sentence that has no punctuation and reads like well, some thought dumped without any attempts to make it helpful for its readers. – GhostCat Sep 01 '17 at 08:03