What is Zero Latency?

Zero Latency means AVIX never disables interrupts and thus does not add a single cycle to the processing of interrupts. What exactly does this mean and why is this so important?

Every embedded system interacts with the outside world. Often this is done using interrupts. A device needing attention interrupts the controller and an Interrupt Service Routine (ISR) is activated in order to deal with the interrupt. This is especially true for PIC24 and dsPIC controllers since these controllers are equipped like no other to deal with interrupts.

Working with interrupts however is often considered difficult. Getting grip on this difficulty is one of the reasons to use an RTOS. But as it proves, almost all RTOSes have a negative effect on the time needed to activate an ISR. The next sections explain why this is the case, what the effect is on your system and what AVIX does to help.

What is the problem with interrupts?

Every RTOS maintains an internal bookkeeping to store information needed for all kernel objects like threads, mutexes and so on. The information in this bookkeeping should of course be correct all the time. When manipulating this bookkeeping, this is broken down in many basic processor operations. The bookkeeping is only said to be updated once all required basic instructions have executed. The update as a whole is said to be a critical section. From the moment the update starts to the moment it finishes, the bookkeeping is in an inconsistent state implying this update may not be interrupted by a piece of software dealing with the same bookkeeping. If the update is interrupted, the piece of software that interrupts, starts working on the bookkeeping while this is in an inconsistent state. The effect of this can be dramatic, even with the simplest of operations as is illustrated next:

Suppose the RTOS internal bookkeeping maintains a linked list of Task Control Blocks containing information about the different active tasks. The RTOS maintains a global pointer called pHead referring the start of the linked list and each element contains a pointer to the next element called pNext. A list could look like shown in the figure to the right.

pNewTCB->pNext = pHead;  pHead = pNewTCB;

Suppose a new task is being activated meaning its Task Control Block must be added to the head of this linked list. Inserting a new element in the list are just two simple operations:

But what happens if between the two statements shown above an interrupt occurs executing the same function. The thread passes the new TCB through pointer pThreadNewTCB and the ISR through pointer pISRNewTCB, leading to the following code sequence:

The four figures below show the situation after each of the numbered steps in this code sequence.
 

As shown in these figures, the new value of the queue head pointer obtained after step 3, is overwritten in step 4, effectivelly destroying the reference to TCB D. The result is TCB D is not added to the queue and is left dangling. This is just wrong and caused by the fact that a code sequence that should not be interrupted is. This is just a very basic sample and regularly RTOS internal bookeeping is much more complex than shown here. To solve this RTOSes disable interrupts during sequences that are not allowed to be interrupted. Doing so, whatever happens the two statements belonging together are executed together and no data corruption occurs.

What is the effect of disabled interrupts?

When an interrupt occurs during the time the RTOS has disabled them, the interrupt will be processed once the RTOS enables them again. The result is a delay in the interrupt handling. Actually for an RTOS this is a strange thing to happen. An RTOS can be seen as an extension of the controllers interrupt model into the users application. It is fair to expect an RTOS to deal with interruption in the most effective way, meaning the lowest possible latency. But disabling interrupts is not just a theoretically less attractive approach, it can lead to disaster if the latency introduced by the RTOS has such a value the interrupt is just handled too late to be in time.

How does AVIX solve this problem?

AVIX simply does not disable interrupts. But still AVIX Interrupt Service Routines are able to communicate with threads using systems calls which is a must for any serious RTOS. AVIX does so with the help of a so-called Deferred Interrupt Handler or DIH. A Deferred Interrupt Handler is a function which is queued by an ISR and activated by the scheduler, the piece of code responsible for activating the threads.
DIH’s are called by the scheduler after all ISR’s have finished and before the scheduler will (re)activate a thread. So effectively a DIH can be considered to have a priority lower than any ISR but higher than any thread. A DIH is not a thread, meaning that, just like an ISR, a DIH is not allowed to make blocking system calls since a DIH must always run to completion. Hence the name, Deferred Interrupt Handler.
When looking at the global picture, system calls are thus only made from code activated by the scheduler, the core entity inside AVIX. As a result, system calls can not be reentered and the above described problem does not occur. Bottom line is this structure makes it redundant to ever disable interrupts resulting in AVIX not adding a single cycle to the processing of the actual ISR code.

Does this mechanism have a performance penalty?

Apart from interrupts never being disabled and thus the shortest latency possible, namely that imposed by the hardware, it may look as if this mechanism introduces a performance penalty. After all, the actual ISR processing is done in two functions instead of one. In practice this proves not to be the case.

From within an ISR a DIH must be queued. But this is only needed in case a call to a system function is required. Because of AVIX system functions not needing to disable/enable interrupts these in turn are more efficient than those in competing products. The function responsible for queuing a DIH is very short, just a few assembler instructions. So the ‘overhead’ from DIH queuing is partly compensated by smaller system functions.

Apart from all kinds of analyses the open source Thread-Metric benchmark shows AVIX to be the fastest in its class, also for the two interrupt based tests in this suite. Read more about performance and the Thread-Metric test suite...