Rule 2. An interrupt routine may not call any RTOS function that might cause the RTOS to switch tasks unless the RTOS knows that an interrupt routine, and not a task, is executing. This means that interrupt routines may not write to mailboxes or queues on which tasks may be waiting, set events, release semaphores, and so on - unless the RTOS knows it is an interrupt routine that is doing these things.
If an interrupt routine breaks this rule, the RTOS might switch control away from the interrupt routine (which. the RTOS think is a task) to run another task, and the interrupt routine may not complete for a long time, blocking at least all lower-priority interrupts and possibly all interrupts.
In the next few figures, we’ll examine these rules.
Rule 1: No Blocking
In Figure we examine the software for the control of the nuclear reactor. This time, the task code and the interrupt routine share the temperature data with a semaphore. This code will not work. It is in violation of rule 1. If the interrupt routine happened to interrupt vTaskTestTemperatures while it had the semaphore, then when the interrupt routine called GetSemaphore, the RTOS wou1d notice that the semaphore was already taken and block. This will stop both the interrupt routine and vTaskTestTemperatures (the task that was interrupted), after which the system would grind to a halt in a sort of one-armed deadly embrace. With both the interrupt routine and vTaskTestTemperatures blocked, no code will ever release the semaphore.
(Some RTOSs have an alternative - and equally useless - behavior in this situation: when the interrupt routine calls GetSemaphore, these RTOSs notice that vTaskTestTemperatures already has the semaphore and, since they think that vTaskTestTemperatures is still running, they let the interrupt routine continue executing. In this case, the semaphore no longer protects the data properly.)
Even if the interrupt routine interrupts some other task, this code can cause problems. If vTaskTestTemperatures has the semaphore when the interrupt occurs, then, when the interrupt routine tries to get the semaphore too, it will block (along with whatever task was running when interrupt occurred). For as long as the interrupt routine is blocked and that may be for a long time if vTaskTestTemperatures does not get the microprocessor back to allow it to release the semaphore all lower-priority interrupt routines and the task that was unfortunate enough to be interrupted will get no microprocessor time.
Some RTOSs contain various functions that never block. For example, many have a function that returns the status of a semaphore. Since such a function does not block, interrupt routines can call it (assuming that this is in compliance with rule 2, which it usually is).
