What is the context of a process? What are the different situations under…

Concept: the context of a process

A process's context is everything the kernel must preserve so that, after being interrupted, the process can later resume as if nothing had happened. It has three parts. The user-level context is the process's own virtual address space — its text (code), data, user stack, and any shared memory — visible to the process itself. The register context is the hardware-register snapshot: the program counter (next instruction to execute), the processor-status register (condition codes/interrupt-enable flags), the stack pointer, and the general-purpose registers holding the process's working data. The system-level context is the kernel-side bookkeeping tied to this process: a static part — its process-table entry, its u-area (per-process kernel data such as open-file and signal information), and its memory-management region/page tables — and a dynamic part — its kernel stack and the stack of nested kernel-mode function-call frames active for it at that moment. Together these three parts are the complete context; saving all of them is what lets the kernel later restore the process exactly where it stopped.

Application: the situations that force a context switch

• The process sleeps (blocks): if a running process must wait for an event — for example a disk I/O completion or a resource held by another process — the kernel saves its context, puts it on a sleep/wait queue, and switches to a different process; the sleeping process's context is restored only once the awaited event occurs and it is scheduled again.

• The process exits: when a process terminates, the kernel saves what it needs of its final context (e.g. its exit status) for a parent that may be waiting, releases its remaining context/resources, and switches the CPU to another process — there is no context left to later resume.

• Return from a system call, not the most eligible process: a system-call trap does not, by itself, require a different process's context — the kernel can service it directly in the calling process's own system-level context. But just before returning to user mode, the kernel checks: is this process still the most eligible one to run (e.g. has its time quantum expired, or has a higher-priority process become ready)? If not, the kernel saves this process's context and switches to the more eligible one instead of resuming it.

• Return from an interrupt handler, not the most eligible process: likewise, a hardware interrupt (timer, disk, keyboard, etc.) can be serviced using the interrupted process's own kernel-stack context — the handler need not belong to a different process. Only when the kernel is about to return to user mode does it re-check eligibility; if the interrupted process is no longer the most eligible one (say, the interrupt itself woke up a higher-priority process), the kernel saves its context and switches away instead of resuming it.

Cross-check

All four situations fit the concept the same way: in each, control has left user mode, and the kernel must be ready to save this process's complete context (user-level + register + system-level) before it can decide what runs next. The first two situations (sleep, exit) always give up the CPU to someone else, so the context is always saved there. The last two (return from a system call, return from an interrupt) are different in kind: entering the kernel via a trap or an interrupt does not itself force a switch — it is only the eligibility check at the point of returning to user mode that decides whether this process resumes or a different process's context is loaded instead. This is exactly why an interrupt or a system call is not automatically a context switch, even though the kernel is always prepared to save context in case one is needed.

So, the context of a process is its complete state — user-level (address space), register (PC/PS/SP/registers), and system-level (process-table entry, u-area, region tables, kernel stack) — and the kernel must save this context in four situations: when the process sleeps, when it exits, and when it returns to user mode from either a system call or an interrupt handler while some other process is more eligible to run.