Processes and System Calls

A browser, a compiler, and a music player can all make progress on one computer. Each needs CPU time, memory, and access to devices. The operating system (OS) provides those resources through services that programs can use without controlling the whole machine.

Give programs useful resources

Virtualization turns a physical resource into a convenient virtual resource. CPU virtualization lets many processes behave as though each has its own processor. The OS runs each for a while and preserves its state between turns. Memory virtualization gives each process its own address space: the addresses its instructions can use.

An abstraction hides details behind a useful interface. A file is an abstraction for stored bytes. A program can call write without knowing whether those bytes go to an SSD or a network drive. A system call provides a controlled way to request a kernel service. Device-specific work stays behind the interface.

Share resources and protect programs

As a resource manager, the OS decides who gets CPU time, memory, and device service. It tries to keep hardware useful while giving programs reasonable access. Sharing also needs protection: one program must not overwrite another's private memory or disable the timer to keep the CPU.

The hardware helps enforce this boundary. Application instructions run in user mode with limited permissions. Kernel code runs with the privilege needed to manage the machine. A timer can interrupt a program even if that program never asks the OS for anything.

For a laptop downloading a file while compiling code, follow three separate jobs:

1. The network device reports arriving data. The kernel makes it available to the downloading process.
2. The OS shares CPU time between the browser, compiler, and other ready processes.
3. The compiler requests file operations to store its output. Its code does not drive the storage controller directly.

Separate the kernel from the interface

The kernel is the privileged core. The shell, desktop, and most system libraries run as ordinary programs, even when they are distributed with the OS. Closing a desktop window does not remove the kernel. A server without a graphical interface still needs process management, memory protection, and device services.

On one logical CPU, user code and kernel code take turns. While the compiler executes ordinary user instructions, the kernel is not also executing on that CPU. System calls, exceptions, and hardware interrupts give it control again.

Choose how, then choose who

A mechanism supplies an operation; a policy chooses how to use it. Saving one process's registers and restoring another's is a mechanism. Choosing which ready process gets the next turn is policy. Keeping these separate lets the OS change its scheduling choices without replacing the switching machinery.

OS design balances useful abstractions, performance, protection, reliability, security, and energy use. The extra CPU time and memory spent on management are overhead. Across the subject, three recurring themes are virtualization, concurrency—activities in progress together—and persistence, which keeps stored data beyond a program's lifetime or loss of power.

Operating systems grew as computers moved from running isolated jobs to serving many activities at once. Each change solved a practical problem: idle hardware, slow interaction, or failures spreading between programs.

From batches to overlapping work

In batch processing, submitted jobs run one after another without interaction with the person who submitted them. Early support software mainly helped load jobs and perform common I/O operations. If the current job had to wait for a device, the CPU could sit idle.

Multiprogramming keeps several jobs in memory. When one blocks for I/O, another can compute. Suppose a job repeatedly computes for 20 ms and waits for disk I/O for 80 ms. Alone, its CPU utilization is 20 / 100 = 20%. With two such jobs and suitable overlap, useful computation can occupy 40% of the elapsed time. The device's delay has not become shorter; otherwise idle CPU time has been filled.

The gain depends on having work ready. Adding jobs cannot push CPU utilization above 100%, and jobs waiting for the same device can still face a bottleneck. Several jobs in memory also need protection: one must not overwrite another or damage the OS's own data.

Make interaction responsive

Time sharing gives processes short turns on the CPU. A terminal or desktop can respond while other programs continue working. Waiting for a batch job to finish before serving another user's keystroke would feel very different.

Concurrency means several activities are in progress during the same period. Their instructions can be interleaved on one logical CPU. Parallelism means instructions actually execute simultaneously on different processing resources. Multiprogramming does not require parallel hardware.

Put services inside or outside the kernel

Linux is monolithic and can load kernel modules. MINIX 3, QNX, and seL4 illustrate microkernel designs. Windows NT and Apple's XNU are commonly described as hybrid designs. A user-mode driver can often be restarted after a crash, while a privileged driver has access that can make its failure system-wide.

Early personal-computer systems such as MS-DOS and classic Mac OS lacked the process memory protection expected today. Modern systems combine OS rules with hardware enforcement. Short CPU turns alone would not stop a program from changing another program's memory; sharing and protection solve different parts of the problem.

An executable on disk can be launched repeatedly. Each launch needs its own changing state so that one instance can pause, resume, or fail independently. That active instance is a process.

Identify the running instance

A program is stored instructions and static data. A process combines a program with its current memory, CPU registers, and I/O state. Three shells can run the same executable while keeping different variables, current directories, and histories.

The program counter (PC) identifies the next instruction. The stack pointer locates the active stack. General registers hold intermediate values. When a process stops running, enough state must be preserved for it to continue at the right instruction with the right values.

Read the address-space picture

A process's address space is the memory its instructions can address. A common teaching layout places code and static data toward lower addresses, a heap above them, and a stack toward higher addresses. The heap supports dynamically allocated objects; the stack supports function calls and local state. In this layout, the heap grows toward higher addresses and the stack toward lower addresses. Actual layouts depend on the system, and malloc implementations can obtain memory in more than one way.

Two processes can print the same virtual address for a variable and still hold different values there. Virtual addresses belong to a process's view of memory. Matching address numbers do not establish shared writable storage.

Start a program

To start a new program image, the OS establishes these pieces:

1. Its executable code and data, with parts loaded when needed on modern systems.
2. An initial user stack and startup information, including the argument strings and argument vector used by the runtime to call main.
3. Memory for dynamic allocation and the initial register state.
4. An I/O environment, including inherited file descriptors.
5. An entry point where program startup code begins.

On Unix, file descriptors are small integers naming open I/O resources. By shell convention, 0 is standard input, 1 standard output, and 2 standard error. They are often connected to a terminal. A process can inherit additional descriptors; the three familiar numbers are not a limit or a promise that every process always has them open.

Inspect the kernel's record

The process control block (PCB) records information the kernel needs to manage one process: PID, state, saved execution context, memory information, open descriptors, parent, owner, current directory, and accounting information. Linux uses task_struct; xv6 uses struct proc. A process table or process list organizes these records.

While a process runs, its live registers are in the CPU. On kernel entry, its user registers are saved on its kernel stack; a context switch also preserves the kernel execution context. The PCB is not a continuously updated mirror of every user register.

For example, a Linux ps listing might contain 8240 8200 S bash and 8291 8240 R ps. The second process has PID 8291 and parent PID 8240, so it is the shell's child. R covers both running and ready processes. A PID identifies a live process within its PID namespace, but after cleanup that number can be reused.

A process can exist without executing an instruction right now. Its state tells the OS whether it can use a CPU or must first wait for something else. This distinction explains why a busy computer can have many processes but only a few executing at an instant.

Decide what the process needs

A blocked process consumes no CPU time while blocked. Its device or event can still make progress. A ready process already has what it needs except a CPU.

The basic transitions are ready → running when selected, running → ready when descheduled, running → blocked when it must wait, and blocked → ready when its event occurs. Event completion makes a process eligible; it does not grant it the CPU immediately. Choosing among eligible processes is the scheduler's job.

Trace overlapping work

Use one logical CPU and ignore switching overhead. Process A computes for 2 ms, waits for disk I/O for 3 ms, and then computes for 1 ms. Process B needs 4 ms of CPU time. A starts first.

At 2 ms, A starts I/O and blocks. B computes while the disk works. At 5 ms, A's I/O finishes, but the OS lets B finish its fourth CPU millisecond before running A. This is a policy choice, not an extra state transition straight from blocked to running.

The total CPU work is 2 + 1 + 4 = 7 ms, and both finish after 7 ms. If A ran to completion before B began, elapsed time would be 2 + 3 + 1 + 4 = 10 ms. CPU utilization would be 7 / 10 = 70%, because no other work filled the I/O wait.

Read states on a real system

Linux ps combines running and ready as R. It shows interruptible sleep as S, uninterruptible sleep, often for I/O, as D, a stopped process as T, and a terminated but unreaped process as Z. A stopped process is not simply waiting for an ordinary I/O completion. A zombie has finished executing and retains only the record needed to report its result.

A new process also passes through creation before it is ready. On a system with four logical CPUs, at most four single-threaded processes can execute simultaneously. Ready queues organize eligible work; blocked lists track the events processes need. A context switch preserves one process's execution state and restores another's when the OS changes which process runs.

fork() creates a child process from the calling parent. Both continue immediately after the call, so one source-code path becomes two executions. Its return value tells each process which role it has.

Branch on all three results

pid_t rc = fork();
if (rc < 0) {
    perror("fork");
    exit(1);
} else if (rc == 0) {
    printf("child %ld\n", (long) getpid());
} else {
    printf("parent of %ld\n", (long) rc);
}

Use <unistd.h> for fork and getpid, <stdio.h> for printing, and <stdlib.h> for exit. On success, the parent receives the child's positive PID; the child receives 0. On failure, the caller receives -1, errno explains the error, and no child exists.

If the parent is PID 5000 and the child is 5001, the parent prints "parent of 5001" and the child prints "child 5001". Neither role is guaranteed to run first. getpid() returns the caller's own PID; getppid() returns its parent's PID. The child does not restart main or repeat instructions before the fork.

Follow private memory and shared I/O

Parent and child begin with matching ordinary memory contents in separate address spaces. If x is 10 before the call and the child sets its copy to 20, the parent's copy remains 10. Even the printed address of x can match: those equal virtual addresses belong to different process address spaces.

Copy-on-write avoids eagerly copying every memory page. Parent and child initially share physical pages with writes protected. When one writes a private page, the kernel arranges a private copy before allowing the write. This preserves the behavior of separate memory while reducing the cost of a child that soon calls exec.

File descriptors behave differently. Their copied entries refer to the same underlying open file description, which includes the current file offset. Sequential reads through an inherited descriptor advance that shared offset. The descriptor table is copied, but the kernel's underlying open-file state can remain shared.

Count only forks that a process reaches

With every call successful, fork(); fork(); leaves four processes: both processes produced by the first call execute the second. A three-iteration loop reached by all processes leaves $2^3=8$ processes, including the original. A fork inside a parent-only branch is reached by fewer processes, so repeated doubling no longer describes the whole program.

Flush buffered text deliberately

printf can leave text in a user-space buffer. fork copies that buffer with the rest of memory. If output is redirected to a fully buffered stream, text printed before the fork can be flushed by both processes at normal exit.

For printf("start\n"); fork();, the usual line-buffered terminal flushes the newline before the fork. A redirected file may retain it and receive two copies. fflush(stdout) before fork() sends the pending text once. The duplicate comes from copied buffered data, not from executing the earlier printf twice.

A process can keep its identity while changing the program it runs. The exec family performs that replacement. Combining it with fork lets a parent continue its work while a child becomes a different program.

Replace the image, keep the process

Successful exec replaces the old code, static data, heap, and stack. The kernel prepares the new program's arguments and entry state, then begins its startup code. The old call site no longer exists, so successful exec never returns to it.

The PID, parent relationship, and current directory survive. Open descriptors survive except those marked close-on-exec. Caught signal dispositions reset to default; ignored dispositions generally stay ignored. Credentials usually remain the same, but an executable's set-user-ID or set-group-ID permissions can change effective credentials when permitted by the system.

Build a valid argument vector

To run wc -l notes.txt, the child can use:

char *args[] = {"wc", "-l", "notes.txt", NULL};
execvp(args[0], args);
perror("execvp");
_exit(127);

The strings are separate arguments, not one combined command line. By convention, args[0] names the program. The final NULL is a pointer marking the end of the array; it is not the string "NULL". Without a valid terminator, the call can read beyond the array.

The lines after execvp handle failure. If the program cannot be found, exec returns -1 and sets errno, for example ENOENT. _exit then ends the child without flushing inherited C output buffers. Returning into the shell loop after failure would accidentally create another shell path.

Read the variant name

The v in execv means arguments arrive as a vector; l variants receive a list. A p variant searches PATH for a program name. An e variant supplies an explicit environment. Linux's underlying system call is execve; the library provides the convenient variants.

execvp("wc", args) searches PATH. execv("wc", args) treats "wc" as a relative pathname in the current directory. An absolute pathname such as /usr/bin/wc can be used where that executable is installed. Exec does not parse shell syntax: a > string in args is just an argument unless a program interprets it itself.

Use the interval before replacement

In the example with parent PID 6000 and child PID 6001, the child becomes wc but remains PID 6001. Its parent can wait for that PID. Before exec, the child can redirect descriptors, connect a pipe, or change directory; the replacement program inherits the prepared environment.

This separation is central to the Unix shell. Windows CreateProcess combines creation and program loading, using parameters to configure the new process. POSIX also offers posix_spawn for a combined operation.

A parent needs to learn whether a child finished and how it ended. Process termination and result collection are separate steps: the child exits, then its parent reaps the kernel's remaining record.

End a process

Returning from main or calling exit(status) ends normal execution. exit flushes C output buffers and runs registered exit handlers. _exit(status) ends without that library cleanup, which is useful after a failed exec in a forked child. By convention, 0 means success and nonzero means failure.

A signal can also end a process. SIGTERM requests termination and can be handled; SIGKILL cannot be caught or ignored. SIGSTOP stops execution and also cannot be caught or ignored; SIGCONT resumes a stopped process. A terminal normally sends SIGINT for Ctrl-C and SIGTSTP for Ctrl-Z to the foreground job. A signal is a software notification to a process, not a hardware interrupt.

Wait for one result

wait(&status) waits for one child and returns its PID. waitpid(pid, &status, 0) selects a particular positive child PID. A finished, unreaped child can be collected immediately. Otherwise, an ordinary blocking wait suspends the parent until a matching result is available.

With WNOHANG, waitpid returns 0 when matching children exist but none has a result ready. A positive result identifies the collected child. A result of -1 is an error: ECHILD means no matching child remains; EINTR means a signal handler interrupted the wait.

Decode the status before using it

int status;
pid_t r;
do {
    r = waitpid(child, &status, 0);
} while (r == -1 && errno == EINTR);
if (r == -1) {
    perror("waitpid");
} else if (WIFEXITED(status)) {
    printf("exit %d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
    printf("signal %d\n", WTERMSIG(status));
}

This uses <sys/wait.h>, <errno.h>, and <stdio.h>. The stored status encodes the manner of termination as well as a result. WEXITSTATUS is meaningful after WIFEXITED succeeds; WTERMSIG follows WIFSIGNALED.

Only the low eight bits of a normal exit value are available. exit(300) therefore yields 44, while exit(-1) yields 255. On Linux, exit(3) commonly produces raw wait status 768; printing that raw integer is not decoding the exit code.

Reap zombies and recognize orphans

A zombie has terminated but retains its PID and result until a wait collects them. It executes no code, so sending SIGKILL cannot remove it. A long-running parent must reap each child. To collect all children, keep waiting after each positive PID, retry on EINTR, and stop on ECHILD; report other errors.

An orphan has lost its parent and can still run. Linux reparents it to an appropriate subreaper or the namespace's init process, which can collect its result later. Ordinary signal permissions depend on user identities and privileges. Running as root grants permissions, not kernel-mode execution.

A shell turns command text into process creation, descriptor setup, and result collection. It is an ordinary user program using the same protected OS services available to other programs.

Launch an external command

For wc -l notes.txt, the shell builds the argument vector and launches the command. The parsed words form a null-terminated argument vector, args:

pid_t child = fork();
if (child == -1) {
    perror("fork");
} else if (child == 0) {
    execvp(args[0], args);
    perror("execvp");
    _exit(127);
} else {
    int status;
    pid_t result;
    do {
        result = waitpid(child, &status, 0);
    } while (result == -1 && errno == EINTR);
    if (result == -1) perror("waitpid");
    else if (WIFEXITED(status)) {
        printf("exit %d\n", WEXITSTATUS(status));
    } else if (WIFSIGNALED(status)) {
        printf("signal %d\n", WTERMSIG(status));
    }
}

This uses <unistd.h>, <sys/wait.h>, <errno.h>, and <stdio.h>. The surrounding shell reads and parses each command, runs this launch path, then displays its next prompt.

Only the child replaces its program; the shell can collect a command crash as a termination result. Built-ins such as cd must change the shell's own state: changing a child's directory would leave the parent shell where it was.

Redirect a descriptor before exec

For ls -l > out.txt, the child opens the destination for writing, creating or truncating it. Then it makes standard output refer to that file:

int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);
if (fd == -1) { perror("open"); _exit(1); }
if (dup2(fd, STDOUT_FILENO) == -1) {
    perror("dup2"); _exit(1);
}
if (fd != STDOUT_FILENO && close(fd) == -1) {
    perror("close"); _exit(1);
}

open needs <fcntl.h>; descriptor calls and _exit use <unistd.h>. The creation mode is filtered by the process's file-creation mask. The fd != STDOUT_FILENO check keeps descriptor 1 open even if open itself returned 1. After successful setup, exec preserves descriptor 1 and ls writes normally without knowing about redirection.

An older approach closes descriptor 1 before opening the file: open returns the lowest unused descriptor. dup2 expresses the destination explicitly. Input redirection similarly connects a readable file to descriptor 0.

Connect two commands

For ls | wc -l, pipe(fds) creates a read end fds[0] and write end fds[1]. The producer child connects the write end to descriptor 1. The consumer child connects the read end to descriptor 0. After duplication, each closes the original pipe descriptors it does not need. The parent closes its copies and waits for both children.

Create both children before waiting for either. A producer can fill the pipe and block; the reader must exist to drain it. The reader reaches end-of-file only when all write descriptors are closed and buffered pipe data has been consumed. An unused write end held by the parent can keep wc waiting forever.

Keep the prompt available

For sleep 60 &, the shell launches the child and presents the next prompt without waiting immediately. It later uses nonblocking waits or responds to SIGCHLD to reap finished children.

Exit status also controls command combinations. make && ./app starts the second command only after success; make || echo failed starts the second only after failure. These decisions use the decoded result, not the raw encoded wait status.

The kernel must let programs compute quickly while stopping operations that could take over the machine. The CPU's privilege mode is the hardware boundary that makes both possible.

Separate computation from privileged control

In user mode, instructions can access permitted process memory and perform ordinary computation. They cannot freely change the hardware configuration that protects other programs. In kernel mode, also called supervisor or privileged mode, the OS can perform the protected operations needed to manage the machine.

Privileged operations include programming the timer, disabling interrupts, installing interrupt handlers, changing memory-translation control registers, directly controlling protected devices, and halting the CPU. If any application could disable the timer, short CPU turns would depend on that application's cooperation.

AArch64 also provides EL2 for hypervisors and EL3 for secure firmware. These names identify hardware privilege levels, not different kinds of user accounts.

Enter at a controlled address

User code cannot raise its own privilege and choose any kernel address to execute. Entry happens through a system call, an instruction-caused exception, or a hardware interrupt. The CPU transfers control to an entry point configured by the OS. Kernel return code restores the saved user state and lowers the privilege level to resume application code.

The kernel also protects its data with memory permissions. A process may have kernel addresses in its virtual layout while still lacking user-mode permission to access them. Knowing an address does not grant access to the bytes there.

Consider an x86-64 Linux application executing hlt, an instruction intended to halt a CPU until an event. In user mode the instruction causes an exception. Linux normally sends SIGSEGV, whose default action terminates that process. The application does not halt the whole computer; the protection boundary turns the attempted privileged operation into an event the kernel handles.

Keep identity separate from mode

A root or administrator process is still a user-mode program while its own instructions run. Its user identity gives it broader permission to request services. It still enters the kernel through controlled paths, and the kernel checks the request.

For example, a privileged maintenance utility may be allowed to open a protected file. The utility asks through a system call; it does not become kernel code merely because the request is allowed. Conversely, when kernel code services an ordinary user's read, it executes in kernel mode even though the caller has no administrative identity.

On one logical CPU, this is a sequence: user instructions, kernel entry, kernel work, return to user instructions. It is not simultaneous execution of a program and a second OS task on that same CPU. Separate logical CPUs can execute different modes at the same instant.

A C program often appears to call an ordinary function when it needs an OS service. Underneath a system-call wrapper, a controlled CPU transition lets kernel code validate and carry out that request.

Distinguish a library call from a kernel request

The C library implements strlen in user space without a system call. printf formats data and may buffer it; a later write transfers bytes through the kernel. A thin read wrapper arranges arguments according to the platform's system-call convention and executes the entry instruction.

POSIX describes interfaces for Unix-like systems. Linux implements many services grouped broadly as process control, file and device operations, information, communication, and protection. A system-call number selects a service from the kernel's dispatch table. Numbers are platform-specific: Linux x86-64 uses 1 for write and 39 for getpid; AArch64 uses 64 for write.

Follow one write request

For write(1, "hi\n", 3) on Linux x86-64, follow the request in order:

1. The wrapper places service number 1 in rax, descriptor 1 in rdi, the buffer address in rsi, and count 3 in rdx.
2. syscall preserves the return address and flags in registers, enters kernel mode, and jumps to the configured entry point. It does not automatically switch stacks.
3. Kernel entry code establishes the process's kernel stack and saves the remaining user state.
4. Kernel dispatch selects write; the implementation checks the descriptor, user-buffer access, and the request before passing bytes toward the output resource.
5. On a complete successful write, the result is 3 bytes. Kernel return code restores user state and resumes the wrapper, which returns to the caller.

Descriptor 1 may name a terminal, file, or pipe. The number alone does not identify the output device. A write can also return a smaller successful byte count; callers that must transfer every byte track the amount actually written.

Check errors at the interface

The kernel treats user pointers and other arguments as untrusted. A request to copy from an inaccessible buffer can fail with EFAULT; controlled copying avoids granting the caller access to kernel memory.

On Linux, a kernel error is a negative error code. The usual C wrapper reports -1 and sets errno. For example, if open("missing.txt", O_RDONLY) fails because the file does not exist, errno is ENOENT. perror("missing.txt") can display "missing.txt: No such file or directory". Inspect errno after a reported failure, not as the primary success test: a successful call need not clear an earlier error.

Account for time spent in the kernel

A call that can finish now may return to the same process. A blocking terminal read can instead put that process into the blocked state and let another run. The input event makes the reader ready; once scheduled, it completes the return path.

Kernel entry adds work beyond a normal function call: saving state, changing privilege, checking arguments, and restoring execution. Library buffering can combine small outputs into fewer writes. On Linux, strace ls runs ls while reporting its system calls, arguments, and results.

Kernel entry can mean a service request, an instruction problem, or a device event. Classifying the cause helps you predict what the OS will do and whether the same instruction should run again.

Ask what caused the event

Synchronous means tied to the instruction being executed. It does not mean the same input causes exactly the same faults on every run. A load can fault when its page is absent and succeed later when that page is resident. Asynchronous means the event's cause is independent of the current instruction, such as a disk completing earlier work.

CPU manuals use these terms in different ways. Follow the cause: deliberate service request, instruction-caused event, or hardware notification.

Dispatch to the right handler

At boot, the OS installs protected handler addresses. A trap or interrupt table maps event kinds to kernel routines. On x86-64, the interrupt descriptor table (IDT) serves interrupts and exceptions; syscall uses an entry address in a special processor register. Only privileged code can configure these destinations.

On an interrupt from user mode, x86-64 hardware saves a return frame on a kernel stack. Entry code saves additional registers before doing the work. The syscall path preserves its initial return state in registers and relies on entry code to establish the kernel stack. Treating all entry paths as identical hardware actions hides an important implementation difference.

Choose the outcome

A valid page that is absent from memory can be loaded, after which the faulting instruction is retried. An access to memory the process may not use normally leads Linux to send SIGSEGV. An exception is therefore not always fatal, and it is not always a request to skip the current instruction.

For an actual x86-64 integer idiv instruction with divisor zero, the CPU raises a divide-error exception. Linux normally delivers SIGFPE; its familiar message mentions floating point even for this integer instruction. AArch64 integer divide instead gives zero for a zero divisor. C division by zero has undefined behavior, so portable C code cannot rely on either machine outcome.

When a disk read finishes, the interrupt handler records completion and makes the waiting process ready. That process may run later. A timer interrupt gives the OS a chance to reconsider the current CPU user, but the handler can also return to that same process.

Distinguish a signal from an interrupt

A hardware interrupt notifies the CPU; a signal notifies a process through the OS. An exception can cause the kernel to send a signal, and one process can request a signal for another through kill. Normal device completions are interrupts without implying program errors.

Kernel code must also protect shared data while events occur. It can disable interrupts briefly on a CPU and use locks where needed. Long interrupt-disabled periods delay device handling; disabling local interrupts alone does not prevent another CPU from accessing shared data.

Running each application instruction in a software simulator would make CPU sharing expensive. Letting an application control the machine without limits would make sharing unsafe. Limited direct execution (LDE) uses ordinary hardware execution with a protected path back to the OS.

Solve two different control problems

Direct execution means a process's ordinary instructions execute on the CPU itself. The OS does not examine and approve every arithmetic instruction. Two problems remain: restricting operations that could damage the machine, and regaining control when a program does not voluntarily stop.

User mode solves the restriction problem. System-call traps let a program request services without choosing arbitrary privileged code. A hardware timer solves the control problem: it can interrupt an application that makes no calls at all. Together, these mechanisms support CPU virtualization at low overhead.

Prepare before applications run

At boot, the kernel configures event handlers and initializes the timer. These setup operations are privileged. Later user programs cannot redirect the handlers or disable the timer to avoid losing their turns.

To start a process, the OS creates its management record and memory image, prepares startup arguments and a user stack, and establishes initial register values. It arranges an initial saved context so the normal kernel-to-user return path can start the program. Conceptually, the process begins by returning from a trap it never made.

The detailed saved-frame layout depends on the CPU and OS. The useful design idea is reuse: the same restoration machinery can resume a suspended process or start a newly prepared one.

Return to the kernel voluntarily

During a system call, hardware preserves the initial return state and transfers control. Kernel entry code saves the additional registers on the process's kernel stack. After completing a nonblocking request, the kernel restores the process and returns to user mode. If the request blocks, another ready process can run first.

When main returns, runtime exit processing ultimately asks the kernel to terminate the process. Its memory can be freed while its termination record remains until a parent reaps it.

Return without cooperation

A cooperative system depends on programs making calls, yielding, or causing exceptions. An endless loop that does none of these can monopolize a CPU. Classic Mac OS illustrates this weakness.

A non-cooperative design uses a timer interrupt to force kernel entry. Consider a teaching model with one logical CPU and a periodic timer every 4 ms. The timer produces 1000 / 4 = 250 ticks per second. A user process stuck in while (1) { } is interrupted at the next tick. The kernel can then run a different ready process; the loop need not reach a system call first.

The tick is an opportunity to act, not a requirement to switch processes. The scheduler may let the interrupted process continue. Timer handling and saved-state restoration are mechanisms; the scheduler's choice is policy. Real response time also depends on kernel work and when interrupts can be handled, so a timer period by itself is not an application response-time guarantee.

Entering kernel mode does not necessarily change the running process. A context switch occurs when the kernel preserves one process's execution state and resumes another's. This requires both user-state preservation and a change in the kernel's own execution context.

Follow A out and B in

For a timer-driven switch on x86-64, trace the layers:

1. A executes user instructions. The timer interrupts it.
2. Hardware moves to kernel mode and saves A's interrupt return frame on A's kernel stack. Entry code saves A's other user registers there.
3. The scheduler chooses B. The switch routine saves A's kernel execution context and restores B's saved kernel context, including its kernel stack pointer.
4. The kernel changes to B's address-space context as needed. It is now running on B's behalf using B's kernel stack.
5. Kernel exit code restores B's user registers. The return instruction restores B's return state and enters user mode. B resumes where it previously stopped.

The first save preserves A's interrupted user execution. The second preserves the kernel's place while handling A. They are not two identical full copies of the same register set. A PCB or associated context structure and the per-process kernel stack work together to preserve the state.

Identify the event and the decision

A blocking call, process exit, or a timer decision can lead to a switch. A device interrupt can make another process ready, and scheduling may then select it. All switching machinery runs in the kernel; an application does not save its own registers to volunteer for interruption.

A context switch preserves the execution state needed to continue. Time passes and the outside world can change: shared file offsets and external inputs are not frozen while a process is paused.

Account for direct and indirect costs

Direct work includes running the scheduler, saving and restoring registers, and selecting an address space. Translation caches may need adjustment; tagged translations can avoid discarding all old entries. Indirect costs follow when B has to refill CPU caches or cached address translations displaced by A. The cost depends on hardware and workload, so use measured or stated values when calculating overhead.

Suppose a switch, including its relevant effects, costs 5 µs and useful CPU turns last 10 ms. Convert 10 ms to 10,000 µs. The switching share is 5 / (10,000 + 5), about 0.05%. For useful turns of 1 ms it is 5 / 1005, about 0.50%; at 0.1 ms it is 5 / 105, about 4.8%.

The denominator includes useful work plus switching time for one repeated cycle. A smaller turn can improve opportunities for interactive work but spends a larger fraction on repeated switching. The timer and switching code make short turns possible; scheduling policy must weigh that cost against responsiveness.