Interrupt handling and polling (A1.3 Operating systems and control systems)

I. Interrupt handling

Peripheral devices signal CPU to gain its attention and request service

- Event = device sends interrupt signal to CPU = CPU pauses, save state and execute interrupt service routine (ISR) to address event

.ISR - function to automatically respond to interrupt signal before returning control to main program

.Event: hardware input, network signal, etc

Instruction flow (INTERRUPT HANDLING)

1. Event causes device to send interrupt signal

2. CPU pauses current program: save current context (registers, program counters, flags)

3. Control moves to ISR

4. ISR executes

5. Return from interrupt: CPU restores saved content and resumes interrupted program

Advantages/strengths (INTERRUPT HANDLING)

- Good for high-frequency environments (v WT, ^ responsiveness)

- Better for battery-powered devices as CPU can enter low-power state when not processing interrupts

- Good for systems with unpredictable events

- v and more controlled latency (delay before data is able to transfer)

Drawbacks (INTERRUPT HANDLING)

- Many interrupts = ^context switching = ^processing overheads (resources consumed not related to direct goal)

- Saving current state and later restoring can be time-consuming and resource-intensive

- Lots of interrupts = ^power consumption (especially critical for battery-powered devices)

- Vulnerable to cause denial-of-service attacks when overwhelmed by flood of interrupts

II. Polling

CPU periodically checks whether each peripheral device needs attention

Advantages/strengths (POLLING)

- Can be implemented easily

- Adequate for low-frequency events

- Better for devices plugged in mains (less concerned about power efficiency)

- Good for systems with predictable events

- Generally less susceptible to attacks

Drawbacks (POLLING)

- v power efficient than interrupt (CPU is active even when no event)

- More battery draining for portable devices

- Inefficient and wasteful where event frequency is low or unpredictable

- Higher and variable/inconsistent latency

- Can overlook security checks if only using regular checks to detect anomalies

III. EXAMPLES

Real world examples (shuffled)

Disk I/O operations

Disk drive complete read/write operation = interrupt signal

- Polling would require CPU to continuously check status of disk drive = ^ processing overheads, v efficiency

Network communications

- Data packet (info transferred from source to destination) arrive at network interface card (NIC) = interrupt signal

- Video streaming: interrupts = real-time processing of audio and video = minimal latency, ^ quality communication

- Polling would require CPU to continually check NIC = ^ processing overheads, potentially missing incoming packets if CPU is occupied

Automatic/self-adjusting thermostat

Periodically check room temperature = polling

Embedded systems

- Need to respond quickly to inputs

- Ex: sensor detect collision = interrupt signal to prompt CPU to deploy airbags

- Using polling = CPU continuously check sensor statuses while possible missing input out of periodical checking

Automatic sprinkler system

Regularly check soil moisture to activate sprinkler system = polling

Mouse and keyboard

- Moves mouse/press key = interrupt signal

.= user inputs are processed in real-time, instant feedback and seamless interaction

- Polling would require the CPU to continuously check the status of the mouse and keyboard

.= unnecessary processing overheads and increased power consumption, especially in battery-powered devices like laptops