One of the most strong points of the RT kernel is the extremely high performance in realtime-related parameters like context switch time and ISR latency.
The performance is not just matter of well written code, a series of design solutions make RT the fastest RTOS for deeply embedded applications.
RT uses efficient double linked circular lists for most of its internal data structures like:
Circular double linked lists have a series of inherent advantages:
Linked lists are dynamic structures but in RT all list elements are statically allocated, nowhere memory is allocated or freed, all memory addresses are finalized at link time.
In RT the context switch operation is performed sycnhronously with a single function call, there are no interrupts/exceptions/tricks involved. The operation is always the same on all architectures:
During the context switch only the function-preserved registers are saved/restored saving time and memory.
The result is a very fast switch from thread to thread, the switch is performed in a very short critical zone and is executed in constant time, there are no tests nor conditional branches during the operation, it is purely sequential code.
In architectures capable of nested interrupts the context switch is only, optionally, performed at the exit of the last ISR, the operation is automatic and transparent.
OS functions called from ISR do not perform a context switch but only handle thread states very quickly, the context switch is done once regardless of how many OS functions have been called.
In RT critical zones are never nested, this means that there is no need to have a nesting counter or to save the current context. This makes the API very efficient, OS code paths minimize load/store operations and conditional branches. Critical zones are entered/left only from the outer function.
All OS functions are provided in two flavours:
Multiple I-Class functions can be invoked from within a critical zone to form a complex atomic operation. For example is possible to signal two semafores and send a message atomically.
The “state checker” debug features makes sure that any call to the OS functions has been performed from the proper context. This rules out, by design, a very common cause of SW failures.
OS functions never return error codes related to wrong parameters. The rationale is: