Polling, interrupts, multitasking and resource allocation
Evaluate event-handling strategies, then explain how the OS coordinates competing processes and prevents resource-management failures.
Event handling is a resource-allocation decision
- evaluate polling and interrupt handling using all six Guide factors;
- apply those factors to keyboard/mouse, network, disk, embedded and real-time scenarios;
- explain task scheduling and resource allocation in multitasking;
- explain resource contention and deadlock as operating-system challenges.
Rapid Recall Deck
Attempt each card first. If a term is new, flip and study it, then answer it again without looking. Mark only secure recall as “Know it”.
The same method is not best in every scenario
Keyboard input
Keystrokes are irregular and a laptop is battery powered. Evaluate polling versus interrupts.
Interrupts are usually preferable because keystrokes are irregular: the CPU need not waste cycles repeatedly checking the keyboard and can conserve energy until a key event occurs. Polling could impose unnecessary overhead. Interrupt handlers still need secure/robust validation so malicious or faulty event sources cannot destabilize the system.
High-frequency embedded sensor
A mains-powered controller samples a sensor at a fixed, predictable interval and requires tightly controlled timing. Evaluate whether polling can be reasonable.
Polling can be reasonable because events are predictable/frequent and the system may benefit from a fixed checking schedule with controlled latency. Mains power makes energy overhead less critical. The judgement still depends on how much CPU time polling consumes and whether other tasks must run concurrently.
Event frequency and timing shape the decision
Scenario grid
For each case, state which approach is likely preferable and give one reason: network packet arrival; disk I/O completion; mouse click; real-time control loop with a fixed sampling period.
- Network packet arrival: interrupts are often suitable because arrivals are asynchronous.
- Disk I/O completion: interrupts allow the CPU to do other work until the operation finishes.
- Mouse click: interrupts avoid continual checking for irregular user input.
- Fixed-period real-time control loop: scheduled polling can be appropriate when predictable sampling and controlled latency are required.
These are context-based choices, not absolute rules.
Multitasking depends on coordinated sharing
Explain the OS role
A browser, video call and backup process run at the same time and compete for CPU time, memory and network/storage resources. Explain how the operating system uses task scheduling and resource allocation to keep the system working, including what happens when processes contend for the same resource.
The OS schedules ready tasks so each makes progress, allocates/protects memory and coordinates shared devices/resources. When processes compete, the OS must resolve contention through scheduling, queues, locks or allocation policies. Good management prevents one task from monopolizing resources and maintains responsiveness/integrity while concurrent work continues.
A circular wait can stop progress completely
Deadlock reasoning
Process A holds the printer lock and waits for the file lock. Process B holds the file lock and waits for the printer lock.
1. Explain why neither process can continue. 2. Name the resource-management problem.
Each process waits for a resource held by the other while refusing to release the resource it already holds. The circular wait means neither can progress: this is deadlock.
Security belongs in the decision, not as an afterthought
Polling: security and robustness scenario
A USB sensor can send malformed values repeatedly, and the program polls the device many times per second. Explain one security or robustness risk created by repeatedly processing untrusted input and one control that could reduce the risk.
Repeated malformed or malicious input could waste CPU time, trigger unsafe program behaviour or exploit weak validation. The polling code should validate inputs and can use bounds/rate controls or other defensive checks so untrusted device data cannot repeatedly drive unsafe processing.
Interrupts: security and robustness scenario
A faulty or malicious device can trigger interrupts extremely rapidly. Explain why the operating system must control which sources may interrupt and how much work an interrupt handler performs.
Interrupts can pre-empt normal execution, so an untrusted or malfunctioning source could consume CPU time or disrupt service by generating excessive events. Systems therefore restrict interrupt privileges/sources and keep handlers controlled so interrupt storms or unsafe handler behaviour do not dominate the processor.
Evaluate with factors; explain with cause → consequence
Paper 1-style mini-set
1. Evaluate interrupt handling rather than polling for a battery-powered wireless device receiving unpredictable network packets.
2. Explain resource contention in multitasking.
3. Explain how deadlock can arise.
- Interrupts avoid repeated idle checks for unpredictable events and can reduce CPU/power use; they provide prompt response when packets arrive, though interrupt overhead/security must be managed. Overall they fit the scenario better.
- Contention occurs when multiple processes simultaneously need the same limited CPU, memory, device or other resource, requiring the OS to schedule/allocate access.
- Deadlock can occur when processes each hold resources while waiting for resources held by one another, creating a circular wait with no process able to proceed.
Finish the learning cycle
IA — main task
Continue Criterion D wrap-up. Verify that important tests demonstrate both normal and failure/edge behaviour.
Paper 1 — short practice
Build a six-factor polling-vs-interrupt evaluation table, then explain multitasking, resource contention and deadlock without notes.
Checkpoint
Do a short IA authenticity/progress check: be able to explain one important code decision and one test result in your own words.