Evolving Operating Systems and Multiprogramming

Early computing environments relied on punch cards, where a single machine handled one card at a time. This sequential approach resulted in severely underutilized central processing units.

To address inefficiency, batch processing systems were introduced. These automated job handling by grouping tasks together, drastically reducing manual intervention. Two primary variants emerged:

• Online Batch Processing: The host system directly managed job input/output streams, often incorporating magnetic tape storage to buffer jobs, which shortened setup delays.
• Offline Batch Processing: Input and output operations were delegated to auxiliary satellite machines. High-speed tape buffers isolated fast CPUs from slower peripheral devices, resolving hardware throughput bottlenecks.

The transition to multi-programming introduced two critical resource-sharing techniques:

• Space Multiplexing: A single CPU time-slices across multiple user programs simultaneously.
• Time Multiplexing: The operating system switches execution context between tasks based on predefined triggers. Switching occurs either when a process initiates an I/O operation (yielding control immediately) or after its allocated time quantum expires. While I/O-driven switches boost overall throughput, excessive time-slicing can introduce overhead that slows individual applications.

Concurrency Versus Parallelism

These terms describe different approaches to handling multiple tasks:

• Concurrency: Multiple processes alternate execution within a given timeframe. The OS rapidly switches contexts, creating the illusion of simultaneous progress.
• Parallelism: Multiple physical CPU cores execute independent instructions at the exact same moment.

Programs Versus Active Processes

A program represents static instructions stored on persistent media. Once loaded into memory and assigned execution resources, it transforms into a process, which encompasses dynamic state information like open file descriptors, memory mappings, and register values.

Scheduling Strategeis

CPU allocation algorithms determine how tasks compete for processing time:

• First-Come, First-Served (FCFS): Executes jobs sequentially. Prone to convoy effects where short tasks wait behind lengthy ones.
• Shortest Job Next (SJN): Prioritizes tasks with minimal expected runtime. Can starve longer-running processes.
• Round Robin: Assigns fixed time quanta to each ready process. Ensures fairness through cyclic rotation.
• Multi-Level Feedback Queue: Dynamically adjusts priorities based on historical CPU usage patterns.

Contemporary kernels typically combine Round Robin mechanisms with adaptive feedback queues to balance responsiveness and throughput.

Process Lifecycle States

Every process cycles through three fundamental states:

• Ready: Waiting for CPU allocation. Triggered upon initial creation, when a time slice expires, or when an I/O wait concludes.
• Running: Actively executing instructions on a core.
• Blocked (Waiting): Suspended awaiting external events, most commonly hardware I/O completion.

Instantiating Processes via Python

New processes originate from existing ones via system calls. Python's multiprocessing module abstracts these OS-level operations.

# Method 1: Target Function Approach
import multiprocessing
import time

def run_worker(worker_label):
    print(f"{worker_label} | Worker initialization complete")
    time.sleep(0.8)
    print(f"{worker_label} | Task concluded successfully")

if __name__ == '__main__':
    worker_proc = multiprocessing.Process(
        target=run_worker,
        args=("Alpha_Node",)
    )
    worker_proc.start()
    print("Parent sequence finished.")
    
    # On Windows, subprocess creation uses 'spawn' rather than 'fork'.
    # The script executes twice unless guarded by `if __name__ == '__main__'`.

# Method 2: Subclass Inheritance Approach
from multiprocessing import Process
import time

class CustomJob(Process):
    def __init__(self, job_identifier):
        super().__init__()
        self.identifier = job_identifier

    def run(self):
        print(f"{self.identifier} | Background routine started")
        time.sleep(0.8)
        print(f"{self.identifier} | Background routine terminated")

if __name__ == '__main__':
    bg_job = CustomJob("Beta_Unit")
    bg_job.start()
    
    time.sleep(1.5)  # Allow child execution window
    print("Parent routine completed.")

Core Process Management APIs

• .join(): Forces the invoking parent to pause until the referenced child terminates.
• .is_alive() & .terminate(): Queries active status and forcibly kills a process without waiting for graceful cleanup.
• Identifier Resolution: os.getpid() retrieves current PID, os.getppid() fetches parent ID, and current_process().pid returns equivalent identifiers from the module namespace.
• Daemon Mode: Setting .daemon = True marks a process as non-persistent. Daemon workers automatically terminate when the primary program exits, regardless of their remaining workload.

Execution Models: Synchronous/Asynchronous vs. Blocking/Non-Blocking

These pairs describe orthogonal dimensions of software design:

• Sync vs Async: Dictates how tasks are dispatched. Synchronous workflows chain tasks sequentially. Asynchronous workflows queue tasks independently and invoke callbacks or futures upon completion.
• Blocking vs Non-Blocking: Describes CPU/thread behavior during I/O. A blocking thread halts entirely while waiting for peripherals. Non-blocking threads return immediately to the scheduler, continuing other operations or polling later.

Optimizing system utilization requires minimizing synchronous I/O waits and transitioning to event-driven or asynchronous patterns wherever possible.

Verifying Inter-Process Memory Isolation

Each process operates within a dedicated virtual address space. Modifications performed in a child process never propagate to the parent's memory scope.

import multiprocessing

shared_buffer = 42

def modify_memory():
    global shared_buffer
    shared_buffer = 99
    print(f"Child view of buffer: {shared_buffer}")

if __name__ == '__main__':
    mem_proc = multiprocessing.Process(target=modify_memory)
    mem_proc.start()
    mem_proc.join()
    
    print(f"Parent view of buffer: {shared_buffer}")
    # Output confirms isolation: parent retains original value (42)

Process Termination and Resource Reclamation

Operating systems enforce strict rules for releasing occupied PIDs:

1. The parent explicitly invokes reaping syscalls (wait or waitpid) after child termination.
2. If the parent exits prematurely or lacks children monitoring capabilities, the system's initialization daemon (PID 1) assumes ownership and handles cleanup.

Zombie and Orphan Processes

Zombie Processes: When a child finishes execution but hasn't been reaped, it enters a zombie state. It releases all executable resources but retains a kernel entry to report exit codes. Accumulation wastes process slots. Remediation includes implementing signal handlers, forcing parent reaping, or restarting affected services.

Orphan Processes: Occur when a parent terminates before its children. The kernel reparents these stragglers to the initialization daemon, which safely reaps them. Orphans pose no system risk and are automatically resolved.