Interrupt causes that the current task is stopped and the CPU begins execution of an interrupt handler. In the real-time systems, it is important that the interrupts were handled at a time. The operating system mechanisms should ensure predictable interrupt latency. The interrupt latency is a time between the generation of an interrupt and a task run. For more information on the interrupt latency in the Sirius RTOS please look at the Real-time performancesection.

When task disables interrupts by calling arLock function, the interrupts will not be generated that suspends the preemption. All system functions are still available and their execution may cause context switching when necessary. It may occur only when the task voluntarily yields its execution or when after the operation some task with the higher priority become ready and expect to run. However, the interrupts are disabled only for task that performs arLockfunction. When a task yields their execution, the scheduler will select next task to run. If a new task does not have disabled interrupts, the interrupts will be performed as usual. Otherwise, the interrupts will not be generated until the arRestore function call or the scheduler runs a task that does not have the disabled interrupts.

When interrupt occurs, the interrupt handler is executed. The code of the interrupt handler is seen by the kernel as executed by interrupted task, until a system function osEnterISR is called. It marks that the interrupt handler begins. When any of the system operation performed in this section except to execute the scheduler, its execution will be delayed to corresponding osLeaveISR function call. When interrupts are nested, the delayed scheduler will be executed when last osLeaveISR will be performed.

SpaceShadow documentation