When an interrupt occurs during the execution of an Interrupt Service Routine (ISR), the system must decide whether to allow the new interrupt to be serviced immediately or wait until the current ISR finishes. This is managed using interrupt priority levels and a mechanism called interrupt nesting. If the new interrupt has a higher priority than the one currently being serviced, the processor can suspend the current ISR, save its state (including the ISR’s own Program Counter and registers), and begin executing the higher-priority ISR. Once the higher-priority ISR completes, the CPU will restore the state of the suspended ISR and continue its execution. However, to prevent issues such as stack overflow or interrupt flooding, many systems temporarily disable further interrupts while an ISR is running, especially in simpler processors. Whether nesting is allowed and how it is handled depends on the processor’s architecture and the operating system’s configuration.

Yes, interrupts can be missed or lost if the processor or interrupt controller is unable to handle them quickly enough. This typically happens when interrupts are disabled during the execution of an ISR, or when the interrupt queue is full. Most processors include an interrupt controller which can buffer incoming interrupts and determine which ones to prioritise. However, if multiple interrupts occur before the system is ready to process them, some may be ignored—particularly lower-priority ones. Additionally, in systems where interrupts are not queued, a new interrupt may overwrite the signal from a previous one if it arrives before the CPU acknowledges the first. This is why many systems use techniques like interrupt masking, priority arbitration, and interrupt queuing. In real-time systems, interrupts are carefully managed using real-time operating systems (RTOS) that support deterministic interrupt handling to ensure no critical interrupt is lost.

Software interrupts are triggered by program instructions to request services from the operating system, while hardware interrupts are generated by external devices needing attention. Software interrupts are often used to implement system calls, where a running application requests access to low-level resources such as file systems, I/O devices, or memory. For example, in assembly language, a specific instruction (like INT 21h in x86 systems) is used to raise a software interrupt. The CPU treats this interrupt similarly to a hardware one—it saves the current state, looks up the corresponding ISR, and jumps to execute it. However, since the interrupt is deliberately generated by the software, it is typically predictable and controlled. Hardware interrupts, by contrast, occur asynchronously and must be handled immediately. Software interrupts provide a controlled gateway between user applications and the privileged kernel mode of the operating system, helping enforce security, stability, and resource management.

Maskable interrupts are those that the processor can ignore or disable using a specific control flag or instruction. This is useful when the processor is handling a critical task and must not be disturbed by less important interrupts. Most general-purpose interrupts are maskable, allowing the CPU or operating system to decide which ones to handle and when. In contrast, non-maskable interrupts (NMIs) are always recognised and cannot be disabled. They are used for critical system events such as hardware failures, memory parity errors, or imminent system shutdowns. Because NMIs bypass standard interrupt masking, they are guaranteed to be acknowledged by the CPU regardless of its current state. NMIs often invoke emergency routines such as saving data, generating system logs, or alerting the user. The use of NMIs ensures that serious issues are never ignored, making them vital for system reliability and fault detection, especially in safety-critical applications.

Edge-triggered and level-triggered interrupts refer to the method by which the CPU detects and recognises interrupt signals. In edge-triggered interrupts, the processor responds to a change in signal—specifically a rising or falling edge (i.e. a transition from low to high voltage or vice versa). This means that the interrupt is triggered by a short pulse, and the CPU reacts only to that momentary change. Edge-triggered systems are more responsive but can miss interrupts if the pulse occurs while interrupts are disabled. In contrast, level-triggered interrupts are based on the voltage level of the signal being high or low for a duration. As long as the signal remains active, the CPU recognises it as an interrupt request. Level-triggered interrupts are more reliable for detecting events that can persist over time but require careful management to prevent repeated servicing of the same interrupt. Each approach suits different types of devices and system architectures, depending on the timing and criticality of the interrupt signals.