I'm reading up on device controllers and am rather confused about the following point:
The device controller informs the CPU that it has finished its operation by causing an interrupt
To me, this seems to defy the intuitive notion of what an interrupt is, ie to "to stop the continuous progress of (an activity or process)". Shouldn't the interrupt occur at the beginning or throughout the controller's execution, and then stop once the controller is finished?
For example, if I send a command on my computer to print a document, I'm imagining there's a message being sent from the printer to the PC to signal the end of its execution, but I certainly wouldn't think of it as an interrupt. If the I/O device has finished execution, shouldn't that free up more resources to the OS?
See, interrupts are basically the reverse of what you are thinking of!
The interrupts are simply to inform CPU that this operation has been completed! Please help removing this process from physical memory and thereby releasing the resources!
The interrupts are triggered at the beginning as well,but,can you imagine as to what will happen if the interrupts would have been hanging everytime withing the process execution? Won't CPU get frustrated because of enormous calls everytime that would have been easily avoided by following the normal procedure!
It's rather an efficient step to cause interrupt at the end(and at the beginning too) because meanwhile CPU is busy doing other task, it becomes the work of device controller to cause interrupt to inform the CPU that Hey CPU, the work has been done, please free the resources and kill the process!
Where is the sad/in-efficient part here???