Run a mock round

A context switch is the act of saving the state of one thread or process and restoring another so execution can resume later. The kernel saves the program counter, registers, stack pointer, status flags and any floating-point state, then loads the saved state of the next runnable entity.

If the switch is between processes rather than threads, the address space changes too, so the page tables are switched and the TLB is flushed or tagged. That makes process switches noticeably more expensive than thread switches within a process.

save regs/PC of A -> choose B -> load regs/PC of B -> resume B

Costs include direct register save and restore, cache pollution because the new workload misses previously cached data, and TLB misses. Mitigations include larger time quanta, thread pools, CPU affinity and reducing syscall frequency. Understanding this overhead explains why very small scheduling quanta hurt throughput.

An operating system manages hardware and provides abstractions so programs do not talk to devices directly. Its main responsibilities are:

• Process management: create, schedule, suspend and terminate processes and threads, and provide synchronisation.
• Memory management: allocate memory, maintain virtual address spaces and decide what stays in RAM.
• File systems: organise persistent data into files and directories with permissions.
• Device and I/O management: provide drivers, buffering and a uniform interface to disks, network cards and peripherals.
• Security and protection: isolate processes, enforce access control and authenticate users.
• User interface and services: shells, system calls and utilities.

apps -> system calls -> kernel -> hardware

It balances competing goals: fairness and throughput in scheduling, latency versus utilisation in I/O, and safety versus performance. Examples include Linux and Windows for general use, and real-time kernels where predictable timing is the priority.

CPUs have at least two privilege levels. In user mode, code cannot execute privileged instructions or touch hardware or protected memory. In kernel mode, the OS kernel can access devices, page tables and privileged registers.

Applications request services through system calls, the controlled entry point into the kernel: read, write, open, fork, mmap and so on. A system call switches to kernel mode, validates arguments, runs the operation and returns to user mode.

ssize_t n = read(fd, buf, size); // traps into the kernel

The boundary matters for performance: each call has overhead, so buffered I/O and batching reduce the number of transitions. It also matters for safety: a bug in user code cannot directly corrupt the kernel, and the kernel checks every pointer and permission. This separation is the foundation of process isolation and of security mechanisms such as address space layout randomisation.

Both are synchronisation primitives, but they express different ideas.

A mutex provides mutual exclusion: it has an owner, it is locked or unlocked, and only the owner may unlock it. Use it to protect a critical section so only one thread at a time touches shared state.

A counting semaphore holds an integer and supports wait (decrement, block at zero) and signal (increment, wake a waiter). It has no ownership, so one thread can signal and another can wait. It is used to limit concurrency or to signal between threads.

mutex_lock(&m); balance += 10; mutex_unlock(&m);
sem_wait(&slots); /* ... */ sem_post(&slots);

A binary semaphore can act like a mutex but lacks ownership, which weakens invariant checking and priority inheritance. Prefer a mutex for locking and semaphores for signalling or resource counting. Condition variables plus a mutex are often clearer for waiting on a state change.

A deadlock is a set of threads each waiting for a resource held by another, so none can proceed. Four Coffman conditions must all hold: mutual exclusion, hold and wait, no preemption, and circular wait.

Thread 1 holds A, wants B
Thread 2 holds B, wants A

Prevention breaks at least one condition. Remove mutual exclusion where possible by making resources shareable. Avoid hold and wait by requesting all resources up front. Allow preemption or rollback. Most practically, impose a global ordering on lock acquisition so a cycle cannot form.

Avoidance uses knowledge of future requests, for example the Banker's algorithm, which grants a request only if the system stays in a safe state. Detection lets deadlocks happen, builds a wait-for graph, finds a cycle and recovers by killing or rolling back a victim. Timeouts are a crude practical mitigation but risk false positives.

The bounded buffer is solved with one mutex plus two counting semaphores, empty and full.

sem_t empty, full;
pthread_mutex_t m;
buffer[N]; int head, tail;

void put(item x) {
    sem_wait(&empty);
    pthread_mutex_lock(&m);
    buffer[tail] = x;
    tail = (tail + 1) % N;
    pthread_mutex_unlock(&m);
    sem_post(&full);
}
void get(item *x) {
    sem_wait(&full);
    pthread_mutex_lock(&m);
    *x = buffer[head];
    head = (head + 1) % N;
    pthread_mutex_unlock(&m);
    sem_post(&empty);
}

empty counts free slots, full counts filled slots, and the mutex protects the buffer and indices. Signal after unlocking so a waiter does not wake and immediately block on the mutex. Initialise empty to N and full to 0. Swapping the wait order, or holding the mutex while waiting on a semaphore, risks deadlock.

A thread pool keeps a set of worker threads alive so tasks avoid per-request thread-creation cost. Core pieces:

• A task queue, typically bounded, holding runnable work.
• A set of workers, each looping: take a task, run it, repeat.
• A synchronisation primitive: a mutex plus condition variable, or a lock-free queue.
• Policies for core and maximum size, queue capacity, and rejection or backpressure when full.
• Lifecycle: graceful shutdown that drains the queue, plus a way to interrupt long tasks.
• Metrics: queue depth, active workers, task latency and rejection count.

submit -> [ queue ] -> worker1..workerN -> result

Sizing depends on the workload: CPU-bound pools near the core count, I/O-bound pools larger but bounded to avoid memory blow-up. Beware blocking tasks starving the pool, unbounded queues hiding overload, and thread-local state leaking between tasks. Dynamic sizing or async I/O often beats a huge fixed pool.

A process is a running program with its own virtual address space, code, data, heap, open file descriptors and at least one thread. The operating system isolates processes from one another, so a crash in one usually does not corrupt another.

A thread is the unit of scheduling inside a process. Threads in the same process share the address space, heap, globals and file descriptors, but each has its own stack, registers and program counter.

Process A
  code + data + heap + file table
  thread 1 (stack, regs)   thread 2 (stack, regs)

Because threads share memory, communication is cheap but synchronisation is required; a data race can corrupt shared state. Processes are isolated, so they are safer but communicating between them needs IPC such as pipes, shared memory or sockets, which is slower and more complex. Creating a process is heavier than creating a thread, so thread pools are common for handling many concurrent requests.

The Banker's algorithm grants a resource request only if the resulting state is safe, meaning some order exists in which all processes can finish.

Inputs are the maximum claim of each process, the current allocation and the available resources. To test safety, simulate: repeatedly find a process whose remaining need is no greater than the current available vector, assume it runs to completion and releases everything, add its allocation back, and repeat. If every process can eventually finish, the order is a safe sequence.

Avail = (3,3,2)
Need  = Max - Alloc
Find Need <= Avail -> run -> Avail += Alloc

If the requested allocation leaves no safe sequence, the request is denied and the process waits, even though resources are momentarily free. The costs are that processes must declare maximum needs up front, the check runs on every request, and it assumes resources are released promptly. It is mostly of theoretical interest; real systems prefer detection plus recovery.