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?
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?