Tami Meredith, Ph.D. CSCI 3431

 Devices need CPU access  E.g., NIC has a full buffer it needs to empty  These device needs are often asynchronous and unrelated to the currently executing process  A change in execution context is needed  E.g., OS must run to empty the full buffer thus interrupting a user's nedit process  We can't predict when they will happen

 CPU periodically checks each device to see if it needs service  Uses CPU time even if nothing needs to be done  Predicable CPU behaviour  Polling is like picking up your phone every 10 seconds to see if a call is there

 Give each device a way to signal the CPU it needs service  When the CPU gets the signal, it stops what it is doing, sees who needs the service, and then provides it  Devices don't wait but CPU behaviour is less predictable  Interrupts are like waiting for the phone to ring and the pausing a conversation to go answer the phone

1. Hardware needs service  signal comes via a CPU line from APIC that is checked after each instruction 2. CPU encounters an error (trap/exception)  identified by internal CPU circuitry 3. Software needs a hardware service (software trap)  Special instruction called to start the interrupt process

1. Interrupt occurs 2. Current process saved 3. Interrupt dispatcher run 4. Interrupt handler run 5. CPU goes back to saved process

 Sometimes called the interrupt handler  Code used for every interrupt  Identifies which interrupt happened  Finds the specific code for that interrupt  Transfers control to the specific interrupt handler needed (the device driver)

 CPU detects an interrupt  Current instruction finishes  CPU reads register on the interrupt controller  Register contains interrupt number which is an offset into the irq_action array/vector (linux)  That irqaaction structure contains the pointers and data needed to call the ISR (called "handler") installed by the device driver

 When a device signals an interrupt it needs attention as soon as possible  This attention is needed so that the device can continue working  However, sometimes the ISR does not need to be totally run so it can be broken into 2 parts and the lower-priority part run later  ISR(1) – actions needed now by device  ISR(2) – actions the device can wait for

 CPU reads interrupt signal  Current instruction finishes  Interrupt dispatcher/handler uses APIC register to find the interrupt service routine (ISR) in the interrupt vector  ISR(1) is run in the current context – must be very careful not to change stack or registers  ISR(1) puts ISR(2) in scheduling queue  Process allowed to resume executing  Time slice ends and scheduler runs  ISR(2) is selected to run and performs remainder of the interrupt

 After the boot process is completed, the CPU sits idle until somebody needs something done – Waits for events  Events are signaled via the interrupt process  Can view an OS as nothing more than a large set of interrupt handlers  System calls cause software interrupts and the library code for the call is invoked by the interrupt handler

 Computer has a hardware clock that that runs the system  Clock has a programmable interval timer that causes an interrupt at some specified interval  The interrupt handler for the timer interrupt is the scheduler