Switching Between Processes

How the Operating System will decide to stop one process and start executing another process when one process is already running on CPU ???

When One process is already on CPU how the OS will take back to control to decide the switching ???

Solution:

1.) Cooperative Approach : System Call

2.)Non - Cooperative approach : Timer Interrupt

Cooperative Approach:

• Process voluntarily gives the control.

• the operating system never initiates context switching from the running process to another process.

• Systems like this often include an explicit yield system call, which does nothing except to transfer control to the OS so it can run other processes

• Applications also transfer control to the OS when they do something illegal. For example, if an application divides by zero, or tries to access memory that it shouldn’t be able to access, it will generate a trap to the OS. The OS will then have control of the CPU again.

• Thus, in a cooperative scheduling system, the OS regains control of the CPU by waiting for a system call or an illegal operation of some kind to take place.

Advantages of Cooperative Multitasking

• Simplicity: Cooperative multitasking is easier to design and implement than.

• Less Overhead: Less system overhead is incurred with fewer context switching.

Disadvantages of Cooperative Multitasking

• Lack of Control: If a process behaves poorly or gets into an infinite loop, it can occupy the CPU very much, which will lead to system hangs or crashes.

• Lower Reliability: They stated that the situation is that malfunctioning programs can collapse the system because the OS cannot force preemptive the programs.

Non - Cooperative Approach:

• A timer device can be programmed to raise an interrupt every so many milliseconds; when the interrupt is raised, the currently running process is halted, and a pre-configured interrupt handler in the OS runs.

• the OS has regained control of the CPU, and thus can do what it pleases: stop the current process, and start a different one.

• OS must inform the hardware of which code to run when the timer interrupt occurs; thus, at boot time, the OS does exactly that. (The Trap Table).

• At boot time OS starts the timer which is privileged operation. Once the timer has started OS feels safe that control will return to it.

  | Feature | Cooperative Process Switching | Non-Cooperative Process Switching | | --- | --- | --- | | Switching Mechanism | A process must voluntarily give up control of the CPU to allow another process to run. | The operating system forcibly interrupts a process and switches to another, often based on a timer or a higher-priority event. | | Control | The process itself controls when it yields. | The operating system controls when to switch. | | Responsiveness | Lower responsiveness, as a long-running process can block other processes from running until it yields. | Higher responsiveness, as the OS can interrupt a long process to give another one a chance to run. | | Overhead | Lower overhead because the OS doesn't need to keep track of time slices or forcefully interrupt. | Higher overhead due to the need for more bookkeeping and management by the OS. | | System Stability | Less stable; a single process that fails to yield can freeze the entire system. | More stable; the OS can always intervene to prevent one process from monopolizing the CPU. | | Use Case | Common in systems with simple, single-threaded applications or embedded systems where processes are well-behaved and a long-running process is unlikely. | Common in modern, general-purpose operating systems to ensure fairness and that all applications can make progress. |

User Stack:

• Definition:

  The user stack is a region of memory allocated to each process in user space. It is used to store information related to the execution of user-level code within that process.

• Purpose:

  The user stack stores function call parameters, local variables, return addresses for function calls, and other temporary data needed by the application.

• Stack Register:

  A dedicated register, typically named the stack pointer (SP) or extended stack pointer (ESP) in x86 architectures, points to the top of the current user stack. This register is crucial for managing the stack's growth and shrinkage as functions are called and return.

Kernel Stack:

• Definition:

  The kernel stack is a separate region of memory allocated to each process, but residing within the kernel's address space. It is used when a process transitions from user mode to kernel mode, such as during a system call or interrupt.

• Purpose:

  The kernel stack is used to store the context of the user process (e.g., user-mode register values, program counter) when entering kernel mode. This allows the kernel to perform privileged operations on behalf of the user process and then restore the user process's state when returning to user mode. It also stores local variables and return addresses for kernel-level functions.

• Stack Register:

  Similar to the user stack, there is a dedicated stack pointer register that points to the top of the current kernel stack when the system is operating in kernel mode. This register is managed by the operating system.

Key Differences:

• Privilege Level:

  The user stack operates in user mode with limited privileges, while the kernel stack operates in kernel mode with full access to system resources.

• Isolation:

  The kernel stack is isolated from the user stack for security reasons, preventing malicious user code from corrupting critical kernel data.

• Usage:

  The user stack is for application-specific data and function calls, while the kernel stack is for handling system calls, interrupts, and other kernel-level operations.

Save and Restore Context

When the OS switches from one process (say Process A) to another (Process B):

1. Process A is running in kernel mode (because only the kernel can perform a context switch).

2. The CPU registers, including the stack pointer (SP) and program counter (PC), contain the state of Process A.

3. The kernel saves the current CPU state (registers, program counter, etc.) into Process A’s kernel stack.

4. Then, the kernel copies essential state info (like register contents, stack pointer, program counter, and scheduling info) from the kernel stack into the Process Control Block (PCB) of Process A.

5. The kernel then loads the saved state of Process B from its PCB (restoring CPU registers and kernel stack pointer).

The user stack is not copied into the kernel stack or PCB.

• Instead, the current value of the user stack pointer (and possibly other registers) is saved in the PCB so that the process can later resume execution with the same user stack contents.

• The actual user stack contents remain in the process’s address space in memory; they are not moved during a context switch.

---

🧾 Summary Table

The user stack is part of the process’s address space — which lives in main memory (RAM) when the process is running.

So:

✅ The “memory” here means primary memory (RAM), not disk.

If the process gets swapped out (for example, under heavy memory pressure), then the OS may move its memory pages — including the user stack — to secondary storage (swap area on disk).
But during a normal context switch, it stays in RAM.

---

⚙️ 2. Where is the PCB (Process Control Block) stored?

The PCB is a kernel data structure — the OS uses it to keep track of each process’s state.

🧠 Think of the PCB as:

• The process’s summary (registers, program counter, stack pointers, scheduling info, etc.)

• Not the full process memory.

Where it’s stored:

• The PCB itself resides in kernel space, which is in RAM (primary memory).

• It’s not stored in secondary storage (hard drive/SSD) during normal operation.

• Only when the system hibernates or swaps out an entire process could its PCB information be written to disk temporarily.

---

📊 Summary Table

There is one kernel stack per process (or per thread) in most modern operating systems.