Assignment 03: Context Switching and CPU Dispatch

Self-Assessment

Topic 1: Context Switching Fundamentals & The PCB

Exercise 1.1: The Mechanism of State Transfer Describe the three precise phases involved in the CPU hand-off during a context switch. Identify the specific data structure utilized during this operation and list three critical pieces of CPU state stored within it.

💡 View Solution

The context switch mechanism involves three distinct phases:

Save Current State: The Operating System meticulously stores the complete CPU context of the currently running process into its corresponding Process Control Block (PCB).
Load Next State: The OS retrieves the saved CPU context for the next selected process from its PCB in main memory and loads it into the CPU’s registers.
Dispatch: The CPU jumps to the loaded Program Counter of the new process to resume execution.

The central data structure utilized is the Process Control Block (PCB). Critical pieces of CPU state stored within it include the CPU Registers (general-purpose, index, segment), the Program Counter (PC), and the Stack Pointer (SP).

Exercise 1.2 (Advanced): Memory Protection and Kernel Isolation During a context switch, system call, or hardware interrupt, the operating system kernel relies on its own stack for execution rather than using the active user process’s stack. Based on the fundamental differences between User Mode and Kernel Mode, explain why this isolation is architecturally necessary.

💡 View Solution

The kernel utilizes its own distinct stack because User Mode and Kernel Mode enforce strict privilege boundaries. A user process operates within an isolated, restricted virtual address space and cannot access kernel memory. If the kernel utilized the user process’s stack during a context switch, it would expose highly privileged execution data to unprivileged user space. Furthermore, relying on a user-space stack introduces severe instability; if the user stack were corrupted, full, or maliciously manipulated, the resulting error during the context switch would cause a Kernel Mode fault, potentially leading to a complete system crash (Kernel Panic) rather than a localized process termination.

Topic 2: The Dispatcher & Scheduling Cycle

Exercise 2.1: Delineating OS Components The CPU Scheduler and the Dispatcher operate sequentially but serve entirely different functions in the Process Scheduling Cycle. Clearly distinguish the roles of both components. What are the three specific responsibilities of the Dispatcher?

💡 View Solution

The CPU Scheduler is the decision-maker; it applies a specific algorithmic policy to select which process from the Ready Queue should receive CPU time next. The Dispatcher is the execution enabler; it takes the process chosen by the scheduler and performs the actual mechanics to hand over CPU control.

The Dispatcher has three key responsibilities:

Context Switching: Saving the old process’s state and loading the new process’s state.
Mode Switching: Transitioning the CPU from Kernel Mode back to User Mode.
Program Jump: Jumping to the specific Program Counter location in the newly loaded process to resume its execution.

Exercise 2.2 (Advanced): Thread vs. Process Context Switching Context switching introduces direct overhead (CPU cycles). Explain why a context switch between two threads belonging to the same process is generally faster than a context switch between two entirely different processes. Identify the specific type of indirect overhead that is avoided during a thread-to-thread switch.

💡 View Solution

A thread-to-thread context switch within the same process is faster because sibling threads share the same virtual address space and memory mappings. When switching between entirely different processes, the OS must update memory mappings and flush or partially invalidate the Translation Lookaside Buffer (TLB). By remaining within the same process boundary during a thread switch, the OS avoids this TLB flush (a major source of indirect overhead) and significantly reduces cache pollution, as the threads are likely accessing the same working set in the CPU caches.

Topic 3: Execution Modes & The Scheduler Paradox

Exercise 3.1: Resolving the Scheduler Paradox A common misconception is that the OS Scheduler is a process that must wait in a queue for its turn on the CPU. Explain why the scheduler is NOT a scheduled process. How does the kernel actually gain control of the CPU to execute scheduling decisions?

💡 View Solution

The scheduler is not an independent user process with its own PCB competing for CPU time; it is a collection of privileged functions and routines embedded within the OS kernel code. The kernel gains control directly and immediately through hardware mechanisms (traps to Kernel Mode) triggered by events. These events include System Calls (a user process voluntarily requesting a service), Hardware Interrupts (like a timer expiring or I/O completion), or Exceptions (program errors like a page fault). Once the CPU is operating in Kernel Mode due to these interrupts, the kernel executes its internal scheduling routines to dictate the next step, acting as the arbiter rather than a participant.

Exercise 3.2 (Advanced): The DMA and Interrupt Lifecycle Direct Memory Access (DMA) allows devices to transfer data without constant CPU involvement. Trace the exact sequence of hardware and software events—including mode switches, queue transitions, and interrupts—that occur when a user process issues a read() system call that is handed off to a DMA controller, up to the point where the process is ready to run again.

💡 View Solution

The user process executes the read() system call, triggering a synchronous software interrupt (trap) that switches the CPU from User Mode to Kernel Mode.
The kernel initiates the I/O by setting up the DMA controller with the device buffer, memory address, and transfer size.
The process making the request is moved to a Waiting state (Device Queue) and voluntarily yields the CPU.
The Scheduler and Dispatcher select a new process, performing a context switch and dropping the CPU back to User Mode to execute the new task while the DMA controller handles the data transfer independently.
Upon transfer completion, the DMA controller generates an asynchronous I/O Completion Interrupt.
The CPU immediately halts the current process, switches back to Kernel Mode, and executes the kernel’s Interrupt Service Routine (ISR).
The ISR verifies the I/O status and moves the original waiting process from the Device Queue back to the Ready Queue.
The scheduler is invoked to decide if the newly ready process should preempt the current one or wait for the next cycle.

Topic 4: Performance, Overhead, and Thrashing

Exercise 4.1: Quantifying Dispatch Latency An operating system runs on hardware with a direct context switch overhead of 8 microseconds.

If the CPU scheduler allocates a time slice (quantum) of 4 milliseconds to each process, what percentage of the CPU’s time is consumed purely by context switching overhead?
If the OS designers reduce the time slice to 500 microseconds to improve interactive responsiveness, what is the new percentage of overhead? What trade-off does this illustrate?

💡 View Solution

First, ensure consistent units. 4 milliseconds = 4000 microseconds. Calculation: (8 microseconds / 4000 microseconds) * 100 = 0.2% overhead.
For a 500-microsecond time slice: Calculation: (8 microseconds / 500 microseconds) * 100 = 1.6% overhead. This illustrates the fundamental design trade-off in multitasking: reducing the time slice improves system responsiveness (processes get the CPU more frequently), but it exponentially increases the percentage of CPU time wasted on dispatch latency rather than doing useful work.

Exercise 4.2 (Advanced): The Collapse of Performance System administrators note that an application server is exhibiting extremely low CPU utilization while the hard drive is constantly reading and writing. Identify this phenomenon. Explain the precise relationship between an excessively high degree of multiprogramming, Cache/TLB pollution, and the onset of this systemic failure.

💡 View Solution

This phenomenon is known as Thrashing, where processes spend more time paging (swapping memory to disk) than executing instructions.

The degree of multiprogramming represents the number of processes loaded into main memory actively competing for the CPU. When this degree becomes excessively high, the system undergoes constant context switching. This rapid switching repeatedly flushes the Translation Lookaside Buffer (TLB) and evicts data from CPU caches, causing massive indirect overhead known as cache pollution. Because the physical RAM cannot contain the working sets for all active processes, the OS is forced into continuous page faults, reading and writing to the disk (swap space). As processes constantly block to wait for these disk I/O swaps, the CPU sits idle, resulting in low CPU utilization alongside extreme disk activity.