A1.3 Operating systems and control systems

The role of an operating system

A computer's hardware understands only machine code: patterns of bits that move data between registers, memory and devices. Writing a program at that level is slow, and the program would only work on one exact model of computer. The operating system sits between the hardware and the programs people use, so that programs can ask for services ("save this file", "draw this window") instead of controlling every component themselves.

Software is divided into two broad kinds. System software keeps the computer itself running, and the operating system is its most important part; utilities such as backup tools and disk checkers also belong here. Application software does a task for the user, such as editing a document, browsing the web or playing a game.

The two kinds depend on each other. A word processor does not contain code for any particular printer or SSD; it relies on the operating system to provide those services, so the same word processor runs on thousands of different hardware combinations.

The operating system as a layer

The layer diagram of a computer system shows where the operating system fits. The user works with applications; applications make requests to the operating system; the operating system controls the hardware. Each layer only needs to know how to talk to the layer next to it, which is why a new graphics card does not mean rewriting every game.

The core of the operating system is the kernel. It is loaded into memory when the computer starts and stays there until it shuts down. The kernel runs in a privileged state of the CPU called kernel mode, in which every instruction and every memory address is allowed. Applications run in user mode, in which instructions that control hardware directly are blocked; an attempt to use one raises an error, and control passes to the kernel.

The split between kernel mode and user mode is a hardware feature, and the operating system depends on it. A bug in a game can crash the game, but it cannot overwrite another program's memory or erase the disk, because only the kernel can carry out those operations.

Abstraction: hiding hardware complexity

The operating system uses abstraction to hide hardware detail. A program that saves a file sees a simple operation: open a file by name, write some bytes, close it. Underneath, the data must be split into blocks, free blocks must be found on the drive, the drive controller must be sent commands in its own format and the directory must be updated. The program sees none of this.

Three mechanisms provide the abstraction. A device driver turns general requests into the commands one model of device understands. A system call is the way a program asks the kernel to do something on its behalf. An application programming interface (API) is the set of documented functions a programmer uses, which in turn makes the system calls.

Manufacturers write drivers for their own devices, so the operating system does not need to know the internal design of every product on the market. A faulty driver is dangerous because drivers usually run in kernel mode: a bug in one can crash the whole system, which is why operating systems now check that drivers are digitally signed before loading them.

A system call switches the CPU from user mode to kernel mode, runs the kernel's code and switches back. This switch costs time, so programs group work together (for example, writing a whole block of data in one call rather than one byte per call).

The path of one "save" request, from a Python program calling open("notes.txt", "w") and write() down to the SSD, shows the layers working together.

The operating system as a resource manager

The second part of the role is managing resources: the CPU, random-access memory (RAM), secondary storage, network connections and devices such as printers and cameras. Several programs and often several users want these at the same time, and there is only a fixed amount of each. The operating system allocates each resource by fixed rules, setting which program gets it and for how long, and makes sure that no program can take what belongs to another.

A single laptop shows the scale of the task. A typical session may have a browser with many tabs, a music player, a messaging app, cloud sync and dozens of background services running at once, yet the computer may have only a few processor cores. The operating system switches the CPU between these tasks hundreds of times a second, so each one appears to be running continuously.

Functions of an operating system

The role of the operating system is carried out by a set of functions. Each one manages one kind of resource or provides one kind of service. Before looking at them, two terms are needed: the operating system manages programs as processes, and a process can contain several threads.

A program is a file of instructions sitting on a drive; a process is that program loaded and running. The operating system records each process in a data structure called a process control block, which holds its identifier, its state, its saved register values (including the program counter), its memory allocation and the files it has open. When the process stops running, these values are saved so that it can continue later exactly where it left off.

A web browser can use one thread to download a page, another to draw it on screen and another to respond to the mouse. Threads share memory, so they can exchange data quickly, but this also means one thread can change data while another is using it, a problem taken up in subtopic B2.3 as a race condition.

Memory management

Every process needs memory for its code and data, and RAM is limited. Memory management keeps track of which parts of memory are in use, gives memory to processes when they start or ask for more, takes it back when they finish, and stops one process from reading or writing another's memory.

Protection works with help from the hardware. Each process sees its own set of addresses, starting from zero, and the operating system and the CPU translate these into real addresses in RAM. A process has no way to name another process's memory, so it cannot damage it. If a program tries to use an address that does not belong to it, the CPU raises an error and the operating system ends the program; Windows reports an "access violation" and Linux a "segmentation fault".

When the processes running need more memory than the RAM holds, the operating system uses virtual memory: part of the secondary storage acts as an overflow area for RAM. Data that has not been used recently is moved out to the drive, and moved back when it is needed.

Virtual memory is organised by paging. Memory is divided into fixed-size blocks: pages in each process's addresses and frames of the same size in physical RAM. A page table for each process records which frame holds each page, or that the page is currently on the drive. Pages of 4 KiB (4,096 bytes) are common.

Because every page and frame has the same size, any page fits in any free frame, so memory does not need to be in one continuous block. When a process uses a page that is not in RAM, the hardware signals a page fault; the operating system then finds a free frame (moving another page out to the drive if necessary), loads the page and lets the process continue.

Virtual memory has a cost. Secondary storage is thousands of times slower than RAM, so a process whose pages keep being moved in and out runs slowly. When RAM is badly overloaded, the computer spends more time moving pages than running programs, a state called thrashing: the drive light stays on and the system almost stops responding. Adding RAM, or running fewer programs at once, is the cure.

File system

Secondary storage holds billions of bytes with no structure of its own. The file system gives that storage an organisation: named files, grouped in directories (folders), with information about each file such as its size, its owner, when it was last changed and who may read it.

Directories form a hierarchy, or tree. The top directory is the root; each directory can hold files and further directories; and every file is found by a path that lists the directories from the root, such as /home/ana/cs/notes.txt on Linux or C:\Users\Ana\cs\notes.txt on Windows. The same file name can appear in different directories without a clash.

Behind the names, the file system manages file allocation. The drive is divided into blocks (often 4 KiB), and a file is stored in as many blocks as it needs, not always next to each other. The file system keeps a table of which blocks belong to which file and which blocks are free. Modern file systems also keep a journal: before changing the structure of the drive, they write a note of the change, so that if the power fails midway the change can be completed or undone when the computer restarts. The allocation table for a small drive shows a file stored in blocks that are not next to each other: when notes.txt grew, the next free block was 42.

Each file also carries permissions that say which users may read it, change it or run it. On Linux a file can be readable by everyone but writable only by its owner; on Windows an access control list can name individual users and groups. These permissions are one form of access control, part of the operating system's security function.

Device management

Every input and output device works differently, and most are far slower than the CPU. Device management installs and uses the right driver for each device, sends requests to devices, and handles their replies. It also shares devices that cannot be used by two programs at once, such as a printer, by queuing the requests.

Speed differences are handled with buffers: areas of memory where data waits until the slower side is ready. A printer may print a page in several seconds, so the operating system stores the whole document in a buffer on the drive (a technique called spooling) and the application can carry on immediately. Devices signal that they have finished or that data has arrived by sending interrupts.

Scheduling

There are usually far more processes ready to run than there are processor cores. Scheduling determines which process runs on each core and for how long, switching between them quickly enough that several programs appear to run at the same time. The choice of scheduling algorithm affects how quickly programs respond, how much work is finished per second and whether any process is left waiting too long.

Security

The operating system protects data and resources from users and programs that have no right to them. It does so in three main ways.

• Authentication checks who a user is before letting them in, usually by a password, a PIN, a fingerprint or a face scan, sometimes combined as multi-factor authentication.

• Access control decides what each authenticated user and each program may do: which files they can read or change, which devices they can use and which settings they can alter.

• Process isolation keeps each process in its own memory space and, on phones, in its own "sandbox", so that a malicious or faulty app cannot reach other apps' data.

Authentication establishes who a user is, and access control then sets what that user may do. A student logged into a school computer has been authenticated, but access control still stops them opening the teachers' files or installing software.

The operating system also protects itself. Security updates fix weaknesses that attackers could use; a built-in firewall filters network traffic; and on phones, an app must ask the user before it can use the camera, microphone or location, and the permission can be withdrawn later.

Accounting

The operating system keeps records of how resources are used: how much CPU time, memory, storage and network data each user and each process has consumed. This accounting serves several purposes. Administrators use it to find which program is slowing a server down; schools and companies use it to enforce quotas such as a storage limit per user; and cloud computing providers use it to bill customers for each second of processor time they rent.

User interface

The user interface is how a person gives commands to the operating system and sees the results. Two kinds dominate. A graphical user interface (GUI) uses windows, icons, menus and a pointer (often called WIMP), or touch gestures on phones and tablets. A command-line interface (CLI) accepts typed text commands and replies in text.

A CLI needs the user to remember commands, but one command can act on thousands of files, and commands can be saved as a script and run again automatically.

Virtualisation

Virtualisation uses software to create a simulated version of hardware. Its main form runs several complete operating systems, each in its own virtual machine (VM), on one physical computer. Each virtual machine behaves as if it had its own CPU, memory, disk and network card; in fact a program called a hypervisor shares the real hardware between them.

The same idea already appears in other operating system functions: virtual memory gives each process the appearance of its own large memory, and the scheduler gives each the appearance of its own CPU. Virtual machines extend it to a whole computer.

There are two types of hypervisor. A type 1 (bare-metal) hypervisor runs directly on the hardware, with no host operating system; data centres use this type (VMware ESXi, Microsoft Hyper-V, Xen). A type 2 (hosted) hypervisor runs as an application on an ordinary operating system, such as Oracle VirtualBox on a laptop, so a student can run Linux inside Windows.

Virtualisation has clear benefits. One large server can replace many lightly used ones, saving money and energy; a virtual machine can be copied, backed up or moved to another server while it runs; software can be tested on several operating systems on one computer; and a virus inside a virtual machine cannot easily reach the host. The costs are some loss of speed (the hypervisor itself uses resources), and a single point of failure, since one hardware fault stops every virtual machine on that server. Cloud computing, taught in subtopic A1.1, is built on virtualisation.

Networking

Almost every computer is now connected to a network, and the operating system provides the networking function. It contains the software that implements the network protocols of the TCP/IP model, drives the network hardware, gives each program a simple way to send and receive data (a socket), and keeps track of which incoming data belongs to which program. It also lets users share files and printers on a local network and manages Wi-Fi and Bluetooth connections. Subtopic A2.1 explains the protocols themselves.

Maintaining system integrity

While users work, the operating system runs many background operations: tasks with no window that keep the system healthy. System integrity means that the system, its files and its data stay correct, complete and consistent while all of this happens. A background task must never leave a file half-written, corrupt the file system or stop the computer from starting.

The operating system protects these operations in several ways. Critical system files can be changed only in kernel mode or by an administrator. Changes to the file system are journaled so they complete fully or not at all. Background tasks run at low priority, so they use the CPU only when interactive programs do not need it, and many updates wait for a restart so that no program is using the files being replaced.

Scheduling the CPU

Why the CPU must be scheduled

A process does not use the CPU all the time. It alternates between CPU bursts, when it calculates, and waits for input or output, such as reading a file or waiting for a key press. While one process waits, the CPU would sit idle unless another process could use it. The operating system therefore keeps several processes in memory at once and moves the CPU between them, so that the processor is kept busy and every process makes progress.

Processes that are ready to run, and are waiting only for the CPU, are held in the ready queue, a queue of processes in memory. The part of the operating system that selects the next process from the ready queue is the scheduler; the rule it follows is the scheduling algorithm.

Moving the CPU from one process to another is a context switch. The operating system saves the current process's state (its register values, program counter and other details) into its process control block, then loads the saved state of the next process so that it continues exactly where it stopped. During the switch no user process runs, so every context switch is overhead: time spent managing processes instead of running them.

Pre-emptive and non-pre-emptive scheduling

Scheduling algorithms fall into two groups. In non-pre-emptive scheduling, a process that has the CPU keeps it until it finishes its burst or chooses to wait (for input, for example). In pre-emptive scheduling, the operating system can take the CPU away from a running process, because its time is up or because a more important process has arrived, and return it to the ready queue.

Pre-emption needs a hardware timer that interrupts the CPU at regular intervals, giving control back to the scheduler even if the running program never gives it up. It is the reason one program stuck in an endless loop does not freeze a modern computer. The price is more context switches, and the risk that a process is interrupted while it is changing shared data.

Measuring a schedule

To compare scheduling algorithms, each one is run on the same set of processes and measured. A process's arrival time is when it enters the ready queue, its burst time is how much CPU time it needs, and its completion time is when it finishes.

Turnaround time matters most for long batch jobs, where the user wants the final result. Waiting time and response time matter more for interactive programs, where the user is watching the screen.

Three further measures compare whole systems rather than single processes. Throughput is the number of processes completed per unit of time. Fairness is whether every process gets a reasonable share of the CPU; a schedule in which one process waits forever is unfair however good its average. Overhead is the time lost to context switching and to running the scheduler itself.

A schedule is drawn as a Gantt chart: a horizontal bar divided into blocks, one for each period a process runs, labelled with the process name and the times at which each block starts and ends.

The process set used for comparison

Every algorithm is applied to the same four processes, so the results can be compared fairly. Times are in milliseconds (ms). A lower priority number means a more important process, so priority 1 is the highest. The "class" column is used only by multilevel queue scheduling.

The total burst time is $5 + 3 + 8 + 2 = 18$ ms, so every schedule of these processes with no idle time ends at 18 ms. The algorithms differ only in the order in which the 18 ms are shared out, and that order changes every waiting time.

First-come, first-served (FCFS)

First-come, first-served runs processes in the order they arrive, each to the end of its burst. It is non-pre-emptive and works exactly like a queue at a shop counter: the ready queue is a first-in, first-out queue, new processes join the back, and the scheduler always takes the process at the front.

Applied to the process set, P1 arrives first at 0 and runs to 5. By then P2, P3 and P4 have all arrived, and they run in arrival order.

FCFS is simple to understand and to program, it has the smallest possible overhead (only one context switch per process), and no process waits forever, because every process eventually reaches the front of the queue. Its weakness is that the waiting time depends heavily on the order of arrival. A long process at the front holds up every short process behind it, like a slow lorry on a single-lane road with a line of cars behind. This is the convoy effect.

While a long calculation holds the CPU, short processes that would quickly have started a disk read or a network request sit in the ready queue, so the disk and network also stand idle. FCFS is therefore a poor choice for interactive systems, where a user who clicks a button should not wait for someone else's long job.

Round robin

Round robin gives each process a fixed, short amount of CPU time in turn, called a time slice or quantum. The ready queue is still first-in, first-out, but a process that has not finished when its time slice runs out is pre-empted and sent to the back of the queue. The CPU cycles through the ready processes like a teacher going round a class, giving each student one question at a time.

The length of the time slice is the most important setting in round robin. Each slice ends with a timer interrupt and, usually, a context switch.

Tracing round robin requires keeping track of the queue at every step, and a tie rule is needed for one case. When a new process arrives at the same moment that a time slice ends, the usual convention is that the new process joins the queue before the pre-empted one; a question may state the opposite rule, and then that rule is followed instead. The trace for the process set with a time slice of 2 ms uses the usual convention, which matters at 2 ms, when P3 arrives just as P1's slice ends.

The figures show the trade-off. Average response time falls from 5.75 ms under FCFS to 2.0 ms, so interactive programs feel faster. But the average waiting time rises from 5.75 ms to 7.25 ms, because long processes are split into pieces that each wait their turn again. Round robin is fair: no process can hold the CPU for more than one slice while others wait, and no process waits forever.

Choosing the time slice

If the time slice is very long, every process finishes within its first slice and round robin becomes FCFS, with the convoy effect. With this process set, a slice of 8 ms gives exactly the FCFS schedule. If the slice is very short, response time is excellent but the CPU spends a growing share of its time on context switches. The process set needs 13 context switches with a 1 ms slice, 8 with a 2 ms slice and only 3 with FCFS.

The share of time lost can be estimated. If a context switch takes $s$ and the time slice is $q$, each slice of useful work costs $q + s$, so the fraction of time spent switching is

A good time slice is long enough that most interactive bursts (a key press, a mouse click) finish within one slice, and short enough that users do not notice the wait between turns. In practice this is a few milliseconds, many times longer than a context switch.

Priority scheduling

In priority scheduling, each process is given a priority, and the scheduler always runs the ready process with the highest priority. Priorities can be set by the operating system (system tasks above user tasks), by the user (lowering the priority of a long download) or by measured behaviour. Processes with equal priority are usually served FCFS.

In the non-pre-emptive version, a running process finishes its burst even if a more important process arrives. Applied to the process set: only P1 has arrived at time 0, so it runs to 5. At 5, the ready queue holds P2 (priority 1), P3 (priority 4) and P4 (priority 2), so P2 runs, then P4, then P3.

Priority scheduling serves the most important work first, which is what a system needs when some tasks have deadlines. Its great weakness is starvation. If high-priority processes keep arriving, a low-priority process may never reach the front. In a busy system, P3 could wait indefinitely.

Starvation is solved by ageing: the longer a process waits, the higher its priority becomes. A low-priority process that has waited long enough eventually has the highest priority of all and runs. Once it has run, its priority returns to normal.

Priority scheduling under pressure: Apollo 11

Priority scheduling has protected real missions. During the Apollo 11 Moon landing in July 1969, the lunar module's guidance computer showed "1202" and "1201" program alarms: it was being given more work than it had time for, because a radar left switched on was stealing processor cycles. The computer's operating system used priority scheduling, so it restarted and dropped low-priority jobs (including a display that the crew had requested) while keeping the high-priority guidance and control tasks running. Mission control judged it safe to continue, and the landing went ahead.

Source: Wikipedia, "Apollo Guidance Computer", section "1201 and 1202 program alarms" (accessed October 2026).

Multilevel queue scheduling

Real systems run very different kinds of process. Interactive programs need quick responses; background jobs such as a large file backup just need to finish eventually; system processes must always run promptly. Multilevel queue scheduling keeps a separate ready queue for each class of process. Each process is placed permanently in one queue when it is created, each queue has its own scheduling algorithm, and a second rule decides which queue gets the CPU.

A typical arrangement has three queues, each with an algorithm suited to its processes.

Between the queues, the usual rule is fixed priority: a lower queue runs only when every higher queue is empty, and a process arriving in a higher queue pre-empts a process from a lower one. An alternative is time-sharing between queues, where each queue receives a fixed share of CPU time (for example 80% for interactive and 20% for batch), which stops the lower queues from starving.

Applied to the process set, the interactive processes P2 and P4 go into a foreground queue scheduled by round robin with a 2 ms slice; the batch processes P1 and P3 go into a background queue scheduled FCFS. The foreground queue has absolute priority.

• 0–1: only P1 (background) has arrived, so it runs.

• 1: P2 arrives in the foreground queue and pre-empts P1.

• 1–3: P2 runs a full 2 ms slice. At 3, P4 arrives at the moment P2's slice ends, so by the tie rule P4 joins the foreground queue ahead of P2 (1 ms left).

• 3–5: P4 runs and finishes. 5–6: P2 finishes.

• 6–10: the foreground queue is empty, so P1 completes its last 4 ms. 10–18: P3 runs.

Multilevel queue scheduling is flexible, because each class gets an algorithm suited to it, and it gives interactive users fast responses. It is also more complex to set up: the number of queues, the algorithm for each and the rule between them must all be chosen. Because each process stays in one queue, a batch process cannot move up however long it waits, so with fixed priority between queues the background queue can starve on a busy system.

Comparing the four approaches

The same 18 ms of work gives quite different results under each algorithm.

Context switches are counted as changes from one process to another after the first process starts.

No algorithm is best on every measure. Round robin has the worst average waiting time here but one of the best response times, while FCFS has the lowest overhead but lets the short process P4 wait 13 ms, so the right choice depends on what the system is for.

General-purpose operating systems such as Windows, macOS and Linux combine these ideas: they give each thread a priority and a time slice, keep interactive work ahead of background work, and adjust priorities as threads run so that nothing starves.

Polling and interrupt handling

Devices need attention at moments the CPU cannot predict: a key is pressed, a network packet arrives, a disk finishes reading a block, a sensor detects movement. The CPU can find out about these events in two ways. It can keep asking each device whether anything has happened (polling), or each device can signal the CPU when something happens (an interrupt). Both are used in real systems, and choosing between them is a trade-off.

Polling

In polling, the CPU, under the control of a program or the operating system, reads a device's status register at intervals to see whether the device is ready or has new data. If nothing has happened, the CPU goes back to its other work and checks again later. The time between checks is the polling interval.

The simplest form is a busy-wait loop that does nothing but check the device until it is ready, which is reasonable only when there is nothing else to do. More often the check is one step in a larger loop, so the program does some work, checks the device, does more work and checks again.

The delay between an event happening and the system responding to it is the event's latency. With polling, an event that happens just after a check is not noticed until the next one, so the worst-case latency is one whole polling interval, plus the time to handle the event.

Polling therefore has a built-in tension. Polling often gives low latency but wastes CPU time on checks that find nothing; polling rarely saves CPU time but makes the system slow to respond, and if data arrives faster than it is collected, a device's small buffer can overflow and data is lost.

Interrupts

With an interrupt, the device starts the exchange instead of the CPU. The device sends a signal to the CPU along a control line when it needs attention, and until then the CPU spends no time on it. Interrupts can come from hardware (a key press, a disk finishing a transfer, a timer reaching zero) or from software (a program making a system call, or an error such as dividing by zero).

The code that handles an interrupt is an interrupt service routine (ISR). Each type of interrupt has its own ISR, and the CPU finds the right one using a table of ISR addresses called the interrupt vector table.

How the CPU handles an interrupt

The CPU does not stop in the middle of an instruction. It checks for interrupts at the end of each fetch–decode–execute cycle, and only then responds. The interrupt-handling flowchart shows the steps that follow.

1. The device raises an interrupt request, which sets an interrupt flag in the CPU.

2. The CPU finishes executing its current instruction.

3. It checks the flag. If interrupts are enabled and this interrupt has a higher priority than the current task, it responds.

4. The current state, including the program counter and the contents of the registers, is saved on the stack so that it can be restored later.

5. The address of the right ISR is found in the interrupt vector table and loaded into the program counter.

6. The ISR runs. It deals with the event, for example by copying a character from the keyboard's buffer into memory, and keeps its work as short as possible.

7. The saved state is restored from the stack, and the interrupted program continues from the next instruction.

Interrupts have priorities. A power failure warning or a timer interrupt is more urgent than a key press, so a high-priority interrupt can interrupt a lower-priority ISR (a nested interrupt), while a low-priority one waits until a higher-priority ISR has finished. The operating system can also mask (temporarily disable) some interrupts while it carries out a short piece of work that must not be broken up.

Interrupts and scheduling

Interrupts make pre-emptive scheduling possible. A hardware timer raises an interrupt at the end of every time slice; its ISR passes control to the scheduler, which can then perform a context switch. When a process asks to read a file, it is moved out of the CPU until the disk's "transfer complete" interrupt arrives, and the CPU runs another process in the meantime. Without interrupts the operating system could take back the CPU only when a program chose to give it up.

Polling and interrupts side by side

The timeline comparison shows both methods responding to the same two key presses. With polling, the CPU stops its work every 5 ms to check, and most checks find nothing; a key press waits until the next check. With interrupts, the CPU is never disturbed until a key is pressed, and the ISR starts almost at once.

Interrupts are not free, however. Each one costs a save and a restore of the CPU's state, often with a context switch, and disturbs the CPU's cache with the ISR's code and data. If events are very frequent, the cost of thousands of interrupts per second can exceed the cost of simply checking at regular intervals. In the worst case, an interrupt storm keeps the CPU so busy entering and leaving ISRs that ordinary work almost stops.

Evaluating polling and interrupts

Six factors determine which method suits a situation. Each factor favours one method in some circumstances and the other in others, so an evaluation applies each of them to the scenario in hand.

Event frequency and overheads. These two factors work together. Polling costs a fixed amount per check, multiplied by the polling rate; interrupts cost more per event (saving and restoring state, possibly a context switch and cache disruption) but nothing between events. When events are rare, almost every poll is wasted and interrupts are cheaper. When events arrive so fast that the device almost always has data waiting, nearly every poll finds work, while an interrupt for every event would mean thousands of state saves per second, so very high frequencies favour polling.

Power source and predictability. On mains power, a few wasted cycles cost little, but on a battery every wake-up drains energy, so phones, wearables and remote sensors use interrupts and let the processor sleep between events. An event that happens at a known rate, such as a temperature reading every second, can be polled at that rate with little waste. Random events, such as a door opening or a key press, suit interrupts because no polling rate fits them.

Controlled latency and security. Many systems need to know the worst-case response time, not just the average. Polling gives a fixed upper limit (the polling interval plus the handling time) that is easy to calculate and test; interrupts are usually faster, but a low-priority interrupt that arrives with others waits for them, so its latency varies with load. On security, ISRs and drivers run in kernel mode, so a bug or a malicious driver can compromise the whole system, and a faulty or attacked device can raise interrupts so often that useful work stops (a form of denial of service). Polling keeps the timing under the program's control, although a polling loop can still be overwhelmed if a device is flooded with data.

Polling and interrupts in real scenarios

Real devices show that the line between the two methods is not sharp. Key presses are irregular and rare by processor standards, so keyboards use interrupts, but a USB mouse is polled by the USB host controller (by default 125 times a second), and the controller interrupts the CPU only when the mouse reports a change. A network card on a quiet connection raises an interrupt for each packet; under heavy load, Linux network drivers switch to a hybrid called NAPI, turning off the card's receive interrupts and polling it, collecting many packets per check, until traffic falls again.

Sources: Wikipedia, "PS/2 port" and "New API" (accessed October 2026).

Disk input and output. Reading from a drive takes far longer than running instructions. The operating system starts the transfer, the drive controller copies the data straight into memory using direct memory access (DMA), and the controller raises one interrupt when the whole block has arrived. Meanwhile, the scheduler gives the CPU to other processes, whereas polling the drive would waste the whole transfer time.

Embedded systems. An embedded system is a computer built into a larger device to do one job, such as the controller in a microwave oven, a digital watch or a car's anti-lock brakes. Many simple embedded systems use a super loop that polls each sensor and button in turn, forever. With few devices and nothing else to do, polling is simple to write, easy to test and has a fixed worst-case latency. Battery-powered embedded systems use interrupts so they can sleep.

Real-time systems. In a real-time system, a result that arrives after its deadline counts as a failure, even if its value is correct. A hard real-time system must never miss a deadline: an airbag controller must trigger the airbag within a few hundredths of a second of a crash. A soft real-time system can occasionally miss one with only a loss of quality, as when a video call drops a frame. Real-time systems use interrupts with carefully set priorities for urgent events, and often poll regular sensors at fixed rates, because a fixed rate gives a predictable, provable worst-case latency.

Multitasking and resource allocation (HL only)

Multitasking

Multitasking is running several processes so that they all make progress over the same period. On a single-core processor, only one process runs at any instant; the operating system switches between them so quickly (often every few milliseconds) that they appear to run at the same time. This is concurrency: the processes are interleaved. On a multi-core processor, several processes really do run at the same moment, one per core, which is parallelism; each core still switches between many processes.

The operating system's tasks in multitasking build on the functions already described. The scheduler shares out CPU time; memory management gives each process its own protected memory; the file system and device management share files and devices; and interrupts and the timer let the operating system take back control. The extra challenge is coordination: processes that share data or devices must not interfere with each other, and none must be left waiting forever.

Process states

At any moment each process is in one of a small number of states, and the operating system moves it between them. The process state diagram shows the five states and the events that cause each change.

• New: the process is being created; memory and a process control block are being set up.

• Ready: the process could run and is waiting in the ready queue for the CPU.

• Running: the process is executing on a core. A single core has exactly one running process.

• Blocked (or waiting): the process cannot continue until something happens, such as a file read finishing, a key being pressed or a resource being released. It is not in the ready queue, so it uses no CPU time.

• Terminated: the process has finished; the operating system reclaims its memory and other resources.

The difference between ready and blocked matters for efficiency. A blocked process is not given the CPU, so a program waiting for a slow network does not waste time slices; the scheduler runs ready processes instead, and the interrupt that signals the end of the wait moves the blocked process back to ready.

Resource contention

Processes share more than the CPU. They compete for memory, files, printers, network connections and data held in shared memory. Resource contention occurs when two or more processes need the same resource at the same time and it cannot serve them all at once.

Some resources can be shared freely: many processes can read the same file at once. Others must be used by one process at a time, such as a printer in the middle of a job or a record that is being updated. For these, the operating system provides locks (also called mutexes, from "mutual exclusion"): a process must acquire the lock before using the resource and release it afterwards, and any other process that asks for the lock is blocked until it is free.

Locks prevent race conditions, in which two threads change the same data at once and the result depends on the exact timing. But locks bring their own problems. A process waiting for a lock is blocked, so heavy contention slows everything down, and processes that hold some locks while waiting for others can block each other permanently.

Deadlock

A deadlock is a situation in which a group of processes are all blocked, each waiting for a resource that another process in the group holds. None of them can continue, so none will ever release what it holds. A classic example involves two processes and two resources: process P1 holds the printer and asks for a file; process P2 holds the file and asks for the printer. Each waits for the other forever.

Deadlock is often confused with starvation, but they are different. In starvation, the system as a whole keeps working, and one process is repeatedly passed over; it could run if the scheduler chose it. In deadlock, the processes involved are all blocked and none can make progress, whatever the scheduler does.

The four Coffman conditions

Deadlock can occur only when four conditions hold at the same time. They were set out by Edward Coffman and colleagues in 1971 and are known as the Coffman conditions.

Resource allocation graphs

A resource allocation graph shows which process holds which resource and which process is waiting for which. Processes are drawn as circles and resources as squares, with a dot for each instance of the resource. An arrow from a resource to a process is an assignment (the process holds it); an arrow from a process to a resource is a request (the process is waiting for it).

The rule for reading a graph is simple when each resource has only one instance: a cycle means deadlock, and no cycle means no deadlock. When resources have several instances (three identical printers, say), a cycle shows that deadlock is possible but not certain, because a free instance may still satisfy one of the requests.

Handling deadlock

Operating systems deal with deadlock in four ways.

1. Prevention: design the system so that at least one Coffman condition can never hold. The most practical is to break circular wait by numbering every resource and requiring processes to request resources in increasing order; then a chain can never loop back. Hold and wait can be broken by making a process request everything it needs at the start, and no pre-emption by forcing a process that is refused a resource to release what it holds and try again. Mutual exclusion usually cannot be removed, because some resources really cannot be shared.

2. Avoidance: before granting each request, the operating system checks whether granting it could lead to deadlock and makes the process wait if so.

3. Detection and recovery: let deadlocks happen, check the resource allocation graph for cycles from time to time, and break any cycle by ending one of the processes (often the one that has done the least work) or taking a resource from it.

4. Ignoring the problem: general-purpose operating systems mostly leave deadlocks between application threads to programmers, because prevention and detection cost time on every request and deadlocks are rare.

Priority inversion

Priority scheduling and locks can combine to produce priority inversion. A high-priority process needs a lock held by a low-priority process, so it is blocked until the low-priority process releases it. That should be brief. But if a medium-priority process becomes ready in the meantime, it pre-empts the low-priority process (which has lower priority), so the lock is not released, and the high-priority process waits for the medium-priority one, even though the two share nothing.

The usual fix is priority inheritance: while a low-priority process holds a lock that a higher-priority process is waiting for, it temporarily runs at the waiting process's priority. The medium-priority process can no longer pre-empt it, so it finishes its work quickly, releases the lock and drops back to its normal priority.

Case study: Mars Pathfinder

NASA's Mars Pathfinder landed on Mars on 4 July 1997 and deployed the Sojourner rover. Its lander computer ran VxWorks, a real-time operating system with pre-emptive priority scheduling. From the day after landing, once the lander had begun gathering weather data, the computer started resetting itself; after each reset, the day's remaining operations were put off until the next day.

The lander used an "information bus", a shared memory area guarded by a lock, to pass data between its software tasks. Three tasks were involved.

Very occasionally, the low-priority weather task held the lock when the high-priority bus task needed it, so the bus task was blocked. If the medium-priority communications task became ready at that moment, it pre-empted the weather task, which therefore could not release the lock. The bus task stayed blocked. A watchdog timer, a hardware safety device that resets a computer when expected activity stops, noticed that the bus task had not run for too long and reset the whole system.

Sources: Wikipedia, "Mars Pathfinder" (accessed October 2026); Mike Jones, "What Happened on Mars?", December 1997, reporting the account given by Wind River, the makers of VxWorks.

Engineers at NASA's Jet Propulsion Laboratory reproduced the fault on an identical copy of the spacecraft on Earth, using a trace of every context switch and lock operation that VxWorks could record. The lock had been created with priority inheritance switched off. Because the spacecraft's software still contained a debugging feature that let engineers change settings remotely, they switched priority inheritance on with a small upload. No scientific or engineering data was lost in the resets.

The case brings several ideas together. Two tasks of different priority contended for one lock (resource contention); the scheduler correctly let the medium-priority task pre-empt the low-priority one, and the result was a priority inversion in which the highest-priority task waited for a task with which it shared nothing. The bus task had a real-time deadline, which is why the watchdog treated the delay as a fault. The fault had appeared in tests before launch but was rare and was given a lower priority than checking the landing software, which shows how a rare timing problem in testing can become a regular one in a busy real system.

Engineers kept priority scheduling and removed only the inversion. With inheritance enabled, the weather task ran at high priority while it held the lock, finished its short piece of work, and released the lock before the communications task could run.

Control system components (HL only)

What a control system is

A control system manages the behaviour of a machine or process so that it does what is wanted: a room stays at 20 °C, a lift stops level with the floor, a car stays in its lane. Many control systems are embedded systems, and most must respond in real time. Every control system follows the same pattern of input, process and output: it takes in information, processes it according to rules, and produces an output that acts on the physical world. Many add a fourth stage, feedback, in which the result of the output is measured and fed back as a new input.

Open-loop and closed-loop control

The block diagrams of open-loop and closed-loop control show the difference that feedback makes. In both, a controller drives an actuator that acts on a physical process. Only the closed-loop system measures the result and corrects itself.

In open-loop control, the controller produces its output from the input alone and never checks the result. A toaster heats for the time set on its dial, whether the bread is thin or frozen; a garden sprinkler on a timer waters at 6 a.m. even if it is raining. Open-loop systems are simple and cheap, but they cannot correct for disturbances, so the result may be wrong.

In closed-loop control, a sensor measures the actual output and this measurement is fed back and compared with the desired value. The difference is used to adjust the output, so the system corrects itself when conditions change. A thermostat measures the room temperature and turns the heater on or off to hold it close to the setting, even when a window is opened.

Three terms describe the loop. The set point is the target value; feedback is the measured output sent back to the controller; and the error signal is the difference between them, calculated by a comparator.

A system with feedback keeps working towards its set point in a continuous cycle: measure, compare, act, measure again. The cycle repeats many times a second in fast systems (a drone's stabiliser) and every few minutes in slow ones (a greenhouse's watering).

With a set point of 20 °C and a measured temperature of 18.5 °C, the error is $+1.5$ °C, so the controller must heat; at 21 °C the error is $-1$ °C, so it must stop heating or cool. The sign of the error gives the direction of the correction, and its size shows how far the process is from the target.

Sensors, actuators and transducers

A control system meets the physical world at two points: sensors bring information in, and actuators produce physical action. Both are kinds of transducer.

A sensor measures a physical quantity and produces an electrical signal that represents it. Most sensors produce an analogue signal, a voltage that varies continuously, so an analogue-to-digital converter (ADC) turns it into binary numbers that the controller can process. A few sensors, such as a door switch, are already digital: on or off.

An actuator turns the controller's output into physical action. Controllers produce small electrical signals, so an actuator often needs a relay (an electrically operated switch) or a driver circuit to switch the larger power that a motor or heater needs. Where the actuator needs a varying signal rather than on or off, a digital-to-analogue converter (DAC) turns the controller's binary output into a voltage.

Controllers and control algorithms

The controller is the decision-making part of the system. It reads the sensor data, applies the control algorithm and sends signals to the actuators. Two kinds of computer are used as controllers.

A microcontroller is a whole small computer on one chip: processor, memory and input/output ports. It costs very little, uses little power and is found in almost every household appliance. A programmable logic controller (PLC) is a rugged industrial computer built to run machinery in factories, power stations and water plants, where it must survive heat, dust and electrical noise and run reliably for years.

PLCs are programmed in simple, standard languages (such as ladder logic, which looks like an electrical circuit diagram) and scan their inputs, run their program and update their outputs in a repeating cycle many times a second. They connect easily to industrial sensors and motors and can be reprogrammed when a production line changes.

The control algorithm is the set of rules the controller follows to calculate its outputs. It is written as a program, and it determines how the system behaves: how fast it reacts, whether it overshoots the target and how often the actuators switch.

Bang-bang control and hysteresis

The simplest control algorithm is bang-bang (on/off) control: the actuator is either fully on or fully off. A basic thermostat switches the heater on when the room is too cold and off when it is warm enough. If both switching points were exactly 20.0 °C, the heater would switch on and off every few seconds as the temperature wobbled around 20.0, wearing out the relay and the boiler. Hysteresis solves this by using two switching points: on below 19.5 °C, off above 20.5 °C, and no change in between.

The program thermostat.py simulates 24 minutes of a room heated by bang-bang control with hysteresis. Each minute it reads the temperature, applies the control algorithm and then models the room: the temperature rises 0.4 °C in a minute while the heater is on and falls 0.2 °C while it is off.

The if and elif (else if in Java) have no final else: between 19.5 °C and 20.5 °C the heater keeps its previous state, and that is the hysteresis. Python constants are written in capitals by convention only, while Java's final makes the compiler stop them being changed. Both versions print one line per minute with the minute, the temperature and the heater state, from 0 18.0 ON to 24 19.8 ON. The heater switches off at minute 7 (20.8 °C), on at minute 14 (19.4 °C), off at minute 17 (20.6 °C) and on again at minute 23 (19.4 °C), as the graph of the 25 readings shows.

The temperature overshoots the band slightly (to 20.8 °C and down to 19.4 °C) because the controller only checks once a minute, so it reacts up to a minute after a threshold is crossed. Checking more often narrows the swing; widening the band reduces how often the heater switches. Choosing these settings is a trade-off between accuracy and wear on the equipment.

Bang-bang control suits systems that change slowly, such as heating a room or a fridge, where small swings do no harm. Systems that need smooth, precise control, such as a car's cruise control or a drone holding its height, vary the actuator's output in proportion to the error instead of switching it fully on or off. The best-known method, PID control (proportional, integral, derivative), combines the size of the error, how long it has lasted and how fast it is changing; it is used widely in industry.

Control systems in real-world applications (HL only)

Analysing any control system

An unfamiliar control system can be analysed in the same steps every time.

1. Purpose and set point: the quantity being controlled and its target value.

2. Sensors (inputs): what is measured and by which sensors, and whether an ADC is needed.

3. Controller and algorithm: the kind of controller and the rules it applies, including thresholds, timings and safety rules.

4. Actuators (outputs): the physical actions produced and the devices that produce them.

5. Feedback: whether a sensor measures the result of the actuators' action. If it does, the system is closed-loop; if not, it is open-loop.

6. Safety and reliability: the effect of a sensor or actuator failing, and the fail-safes built in.

The automatic irrigation system shows the steps applied to a farm or garden. A soil moisture sensor measures the water in the soil; the grower sets a target, say 30% moisture; the microcontroller switches a pump on through a relay when the soil is too dry and off when it is wet enough. The water raises the soil moisture, and the sensor measures the change, so the loop is closed.

The table applies the same analysis to the other common applications.

Autonomous vehicles

A self-driving car is a set of closed-loop control systems working together. Sensors build a picture of the road many times a second: lidar measures distances with laser pulses, radar tracks the speed of other vehicles even in rain or fog, and cameras read signs, lane markings and traffic lights. The controller combines these inputs, often using machine learning to recognise objects, plans a path, and sends signals to the steering, accelerator and brake actuators. The resulting motion changes what the sensors see on the next cycle, closing the loop.

Waymo, owned by Google's parent company Alphabet, runs one of the largest robotaxi services, and its scale shows how far such control systems are now trusted on public roads.

Source: Wikipedia, "Waymo" (accessed October 2026).

The several kinds of sensor provide redundancy: when one is weak (cameras in low sun, lidar in heavy snow), the others still work. The control system must also respond in hard real time: at motorway speed a car covers about 30 metres every second, so a decision that arrives late can mean a collision.

Smart thermostats

The Nest Learning Thermostat, launched in 2011, added learning to the classic closed-loop thermostat. During its first weeks in a home, it records each manual change of temperature and turns these into a daily schedule, so the set point itself varies through the day. Its occupancy sensors, together with the locations of the residents' phones, show when the house is empty, and the set point then drops to an energy-saving value. Google bought Nest Labs for US$3.2 billion in January 2014.

Source: Wikipedia, "Nest Thermostat" and "Google Nest" (accessed October 2026).

The underlying loop is unchanged (measure, compare, switch the heating), but the controller now adjusts its own set point from data about the users, which saves energy while recording when people are at home, a privacy and security concern.

Safety and fail-safe design

Control systems act on the physical world, so a fault can cause damage or injury. Designers therefore ask what happens when each component fails and build in fail-safes: the system is designed so that a failure leaves it in a safe state. A lift's brakes are held off by power, so a power cut applies them; a traffic controller that detects conflicting greens switches every signal to flashing amber or red; a gas boiler's valve closes if the flame sensor stops detecting a flame.

Other safety measures include redundancy (two or three sensors measuring the same quantity, with the controller comparing them and rejecting one that disagrees), watchdog timers that reset a controller that stops responding, limits that the control algorithm will never exceed, and the ability of a human operator to override the system.

Boeing 737 MAX and MCAS

The Boeing 737 MAX shows what can happen when a closed-loop system relies on a single sensor. Its Maneuvering Characteristics Augmentation System (MCAS) pushed the aircraft's nose down whenever the angle of attack (the angle between the wing and the oncoming air) read too high, using only one angle-of-attack sensor at a time. When that sensor failed and reported a falsely high angle, MCAS pushed the nose down again and again, against pilots who had not been told the system existed.

Source: Wikipedia, "Boeing 737 MAX groundings" (accessed October 2026).

Each part of the fix maps to a safety principle: two sensors give redundancy, so one faulty reading no longer drives the system; limiting activation keeps the controller's authority within safe bounds; and the pilot override and new training restore the human in the loop, which the original design had left out.

Stuxnet: attacking the control loop

Control systems can also be attacked deliberately. Stuxnet, a computer worm discovered in June 2010, reprogrammed the Siemens programmable logic controllers that drove uranium-enrichment centrifuges at Iran's Natanz facility, speeding the motors up and slowing them down until the stress damaged the machines, while replaying normal-looking readings to the operators. It therefore attacked both halves of the loop, changing what the actuators did and faking the feedback that humans relied on. Control systems consequently need the same security as other computers: authentication before a controller's program can be changed, isolation from other networks and independent checks on sensor data.

Source: Wikipedia, "Stuxnet" (accessed October 2026).

Exam focus

Operating systems and control systems are examined in Paper 1, Section A, in extended-response questions that are broken into parts of rising difficulty. The SL statements use four command terms. Describe (the role and the functions of an operating system) needs a detailed account with specific features, not a list of names. Compare (scheduling approaches) needs similarities and differences that refer to both algorithms throughout, ideally point by point. Evaluate (polling and interrupts) needs strengths and limitations of both methods, applied to the scenario, and a supported conclusion. Gantt charts and waiting-time calculations appear as Construct and Calculate parts within scheduling questions.

On the HL paper, the same questions carry extra parts on the HL-only statements: Explain multitasking, resource contention and deadlock, usually with a scenario of named processes and resources; Describe the components of a control system; and Explain how a given control system works, often an unfamiliar one described in the question. Typical parts are worth 2–4 marks, with a final 4–6 mark Evaluate or Explain part.

The full exam-style question is set on a small office server running four processes, with times in milliseconds.

Gantt chart questions are mechanical once the rules are fixed, so marks are usually lost on details: a process put back in the queue in the wrong place, an arrival missed, or a waiting time calculated as start time minus arrival time for a process that ran in several pieces.

On the HL paper, control system questions reward precise vocabulary. "Sensor", "actuator", "controller", "set point" and "feedback" each have exact meanings, and answers that mix them up (the sensor "turns on the heater") lose marks even when the idea is right.

Practice questions

1. Define the term operating system. [1]

2. Distinguish between a program and a process. [2]

3. Describe how virtual memory allows a computer to run more programs than its RAM can hold, and state one disadvantage. [3]

4. Outline the purpose of a device driver. [2]

5. Four processes arrive in the ready queue: W (arrival 0, burst 6), X (arrival 2, burst 2), Y (arrival 3, burst 4), Z (arrival 5, burst 1). Construct Gantt charts for FCFS and for round robin with a time slice of 3 ms, and calculate the average waiting time for each. Assume that a process arriving as a time slice ends joins the queue before the pre-empted process. [6]

6. Explain why priority scheduling can lead to starvation, and how ageing prevents it. [3]

7. Compare round robin scheduling with multilevel queue scheduling. [4]

8. A fitness tracker counts steps using an accelerometer and runs for a week on one charge. Evaluate the use of interrupts rather than polling to detect when the user starts moving. [4]

9. (HL only) Explain the difference between deadlock and starvation. [3]

10. (HL only) An automatic car park barrier opens when a valid ticket is inserted and closes when a sensor detects that the car has passed. Identify one sensor, one actuator and the role of the controller, and explain one fail-safe the barrier should have. [5]

Summary

• An operating system is system software that hides hardware complexity behind abstractions (APIs, system calls and device drivers) and manages the CPU, memory, storage and devices; the kernel runs in a privileged kernel mode.

• Its functions are memory management (allocation, protection, virtual memory and paging), the file system (files, directories, permissions), device management, scheduling, security (authentication, access control, process isolation), accounting, the user interface (GUI or CLI), virtualisation (virtual machines run by a hypervisor) and networking, while background operations keep the system intact.

• Scheduling shares the CPU between processes; each change of process is a context switch, which is overhead. Pre-emptive scheduling can take the CPU away from a running process.

• Waiting time = turnaround time − burst time; turnaround time = completion time − arrival time; response time = first run − arrival time. A Gantt chart shows which process runs when.

• FCFS is simple with low overhead but suffers the convoy effect; round robin is fair with good response time, but its overhead depends on the time slice; priority scheduling serves urgent work first but risks starvation, cured by ageing; multilevel queue gives each class of process its own queue and algorithm.

• Polling checks devices at intervals: simple, with predictable latency, and efficient for very frequent or regular events, but wasteful and power-hungry for rare ones. Interrupts let devices signal the CPU, which saves its state, runs an ISR and restores its state: efficient and low-latency for rare, unpredictable events, but costly when events are very frequent.

• HL: multitasking interleaves processes on each core; processes move between new, ready, running, blocked and terminated. Deadlock needs all four Coffman conditions (mutual exclusion, hold and wait, no pre-emption, circular wait) and shows as a cycle in a resource allocation graph; priority inversion is fixed by priority inheritance.

• HL: open-loop control acts without measuring the result; closed-loop control uses sensors to feed back the output, compares it with the set point and acts on the error. Sensors and actuators are transducers; a microcontroller or PLC runs the control algorithm, such as bang-bang control with hysteresis.

• HL: real control systems (thermostats, lifts, washing machines, traffic signals, irrigation, security systems, automatic doors, autonomous vehicles) are analysed by their sensors, actuators, controller logic and feedback, and need fail-safes and redundancy because failures can cause harm.

Self-check

• To do:

  I can describe how an operating system hides hardware detail through APIs, system calls and device drivers.

• To do:

  I can explain the difference between kernel mode and user mode and why it protects the system.

• To do:

  I can describe each function of an operating system with a precise detail or example.

• To do:

  I can calculate a physical address from a page number, a frame number and an offset.

• To do:

  I can explain how background operations are run without harming system integrity.

• To do:

  I can draw a Gantt chart for FCFS, round robin, priority (both versions) and multilevel queue scheduling.

• To do:

  I can calculate waiting, turnaround and response times and their averages from a Gantt chart.

• To do:

  I can explain the convoy effect, starvation and ageing, and the effect of the time slice on round robin.

• To do:

  I can compare two scheduling algorithms point by point, with both in each point.

• To do:

  I can list the steps the CPU takes to handle an interrupt.

• To do:

  I can evaluate polling against interrupts for a named scenario using the six factors and reach a conclusion.

• To do:

  I can draw the process state diagram and explain each transition. (HL only)

• To do:

  I can state the four Coffman conditions, draw a resource allocation graph and decide whether it shows deadlock. (HL only)

• To do:

  I can explain priority inversion and priority inheritance using the Mars Pathfinder case. (HL only)

• To do:

  I can draw open-loop and closed-loop block diagrams and identify the sensors, actuators, controller and feedback in an unfamiliar control system. (HL only)