8.1.3 Implementation

The pseudocode from the previous section looks good. It is clean and clearly separates the ISR from the handler thread. At the same time, the interface between the ISR and the handler thread is quite simple and clear.

There is one problem.

rtkSemphoreV can potentially trigger a thread context change. If the thread being interrupted by the UART receive event has a lower priority than the handler thread, the call to rtkSemphoreV initiates a context switch.

The problem is that the interrupted thread is now suspended half way through an ISR. The problem is not with the I-bit (which is cleared when the ISR gets control). Afterall, a context switch resumes the value of the I-bit. The problem is that potentially, we can have registers of half-finished ISR instances saved on the stack for all threads except those in one priority queue (the highest priority queue). This is a waste of space, although it is still ``correct'' given enough stack space, and that there is nothing else to do after rtkSemaphoreV in the ISR.