When an interrupt occurs, the current task is preempted and the CPU begins execution of an interrupt service routine (ISR). In real-time systems, it is critical that interrupts are handled deterministically. The operating system must ensure a predictable interrupt latency, defined as the time elapsed between the generation of an interrupt and the start of the corresponding task or handler. For detailed analysis of interrupt latency in Sirius RTOS, please refer to the Real-time performance section.

When a task disables interrupts by calling the arLock function, peripheral interrupts are suppressed, which effectively suspends preemption. All system functions remains accessible; however, their execution may trigger a context switch if a task voluntarily yields or if a higher-priority task becomes ready to run as a result of the operation. Notably, interrupts are only disabled for the specific task that invoked arLock. When a task yields, the scheduler selects the next task to execute. If the new task has not disabled interrupts, they will be serviced as usual. Otherwise, interrupts remain suppressed until arRestore is called or the scheduler switches to a task that does not have interrupts disabled.

Upon an interrupt trigger, the interrupt handler begins execution. The kernel treats the handler code as being executed within the context of the interrupted task until the osEnterISR function is called. This call explicitly signals the start of the ISR. Any system operations performed within this section that would normally trigger the scheduler are instead deferred until the corresponding osLeaveISR call. In scenarios involving nested interrupts, the deferred scheduler will only be executed when the final osLeaveISR associated with the outermost interrupt is performed.