POLLING AND INTERRUPTS
When the state of the hardware changes, such as when a serial port receives data or transmission is completed, the device driver needs to know about this change so that it can handle the changed state. Consider a UART serial transmission device. For reception, the device driver needs to move the data from the hardware buffer into its software buffer before more data arrives and overwrites it. Also, the system will need to copy data for transmission from software buffers to the hardware buffers as transmissions are completed. The issue then is, how does the system know to respond to changes of state by the hardware? Software can use two different methods to handle hardware changes of state: polling and interrupts.
With polling, a separate thread runs that continuously checks the state of a hardware register or hardware flag. If it has changed, then the change is acted upon. Such a thread would typically sleep for a period in its loop to not overburden the CPU, as shown in Figure 31-1. Polling in this manner is effectively a periodic activity. If the period is too long, some events may be missed. If the period is too short, the thread may consume too much of the CPU time. Polling is suitable where the hardware in question doesn’t raise interrupts or where only the occasional poll is required. Polling can be simpler to implement than interrupts.
If polling is used in a driver, then it does nothing more than move the data between its buffers and ...