Page | 67 Even if the hardware
can disable interrupts, the software must also be able to enable or disable them. For example, on return from an interrupt service routine, after the software has done whatever the interrupt requested, the software must re-enable the interrupt as it returns to the code which was interrupted. Furthermore,
if the output queue is empty, there is no point in responding to an interrupt from the output device when it is ready to transfer more data a similar argument can be made when the input queue is full. On most machines, there are special instructions to enable and disable interrupts on some, these instructions apply to all interrupts at the same time, while other machines allow groups of devices to be enabled or disabled as a group.
In addition,
it is usual to include, in each device's control register, one or more interrupt enable bits corresponding to each condition the device can sense that might because for an interrupt request. If the interrupt enable bit fora condition is set, then when that condition is detected, there will bean interrupt request. It should be noted that the disabling an output device's ability to request interrupts when the output queue is empty and enabling that device when data is put in the queue is a special purpose solution to a general problem, the producer-consumer problem.
The device is the consumer, and the application is the producer, and the general problem is to prevent the consumer from attempting to use data that has not yet been produced. In any producer-consumer system, whether the system is all in hardware, all in software,
or mixed between the two, there must be some synchronization mechanism to make the consumer wait until data is available
Share with your friends: