what is meant by disabling interrupts?

Question

When entering an inteerupt handler, we first "disable interrupts" on that cpu(using something like the cli instruction on x86). During the time that interrupts are disabled, assume say the user pressed the letter 'a' on the keyboard that would usually cause an interrupt. But since interrupts are disabled, does that mean that:

1. the interrupt handler for 'a' would never be invoked, since interrupts are disabled in the critical section or
2. the interrupt will be handled by the os but delayed, until interrupts are enabled again. Specifically, will the user need to press 'a' again, if the first time he pressed 'a' was at a time when interrupts were disabled ?

Answer 1

The simple answer is that an interrupt automatically disables further interrupts. Interrupts should and are disabled for the shortest time only. The first instruction in the original AT BIOS keyboard ISR was STI to enable interrupts.

The happy answer is that the PIC prioritizes the hardware interrupts and even with interrupts enabled only the timer interrupt IRQ0 can interrupt the keyboard ISR. Of course a NMI can occur either way but happily this never occurs on a current PC.

Answer 2

Often, one interrupt is "queued" by hardware.

[An interrupt is often just a logic gate that can stick on; once it's on, it stays on for a while.]

If the user hit 'a' once only during the interval when interrupts were disabled, it would register as an interrupt when they were re-enabled.

If the user somehow managed to hit 'a' twice during the interval when interrupts were disabled, one would register as an interrupt when they where enabled. Whether it was the first or the second depends on the exact logic gate configuration.

Answer 3

The answer is that it depends on whether you were already handling a keyboard interrupt.

Most interrupt service routines (ISR) have code at the termination of them which informs the hardware that it has been "serviced." In the case of the keyboard controller, commands are written to it acknowledging the received bytes. It is at the time of acknowledgement that the keyboard controller hardware stops using electricity to signal an interrupt condition.

If you are handling a non-keyboard interrupt, let's say the fire alarm interrupt, then the keyboard hardware which electrically asserts the interrupt will trigger as the key is pressed. The electrical signal is ignored until the CPU has interrupts enabled again. At the end of servicing the fire alarm interrupt, the fire alarm ISR acknowledges whatever data and re-enables interrupts on the CPU. Immediately, the CPU enters an interrupt because the keyboard controller is still electrically signalling an interrupt condition.

If you are handling a keyboard interrupt, and the user quickly types a second keystroke during the execution of your keyboard ISR, then there is a chance of missing the data from the second keystroke, or of receiving it later if at all. In particular, if the ISR resets the keyboard controller through an acknowledge, but the ISR has not actually received all the available bytes out of the keyboard controller, then that is a problem.

Often, an ISR will first handle the interrupt which triggered its activation, then after acknowledging the interrupt, poll the device to see if it has received more data since the first interrupt. If so, generate a software interrupt to re-enter the ISR and service the device.