Product Information
Community and Support

RT Performance

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.

Data Structures

RT uses efficient double linked circular lists for most of its internal data structures like:

  • Ready List.
  • Timers List.
  • Queues of Threads.

Circular double linked lists have a series of inherent advantages:

  • Constant time element insertion and removal.
  • Purely sequential code for insert and removal operations without tests nor conditional branches.
  • Efficient list traversal and insertion.
  • Very efficient code for ordered lists handling.

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.

Context Switch

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:

  1. Enter critical zone.
  2. Save registers on task stack.
  3. Swap tasks Stack Pointers.
  4. Restore registers from task stack.
  5. Leave critical zone.

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.

ISR Handling

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.

Critical Zones

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:

  • Normal function that can be called from outside critical zones.
  • “I”-Class functions designed to be called from within critical zones.

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.

Call Protocol

OS functions never return error codes related to wrong parameters. The rationale is:

  • Checking parameters is costly and adds conditional branches. You only need that at development time, in RT checks can be disabled in the deployed code. Failed parameter checks cause a system halt detected by the debugger.
  • Even just returning an “OK” error code takes instructions and code space.
  • Error codes adds uncertainty, it is never perfectly clear if returned codes have to be tested and how to handle failures. This potentially adds complexity also in the caller code. Most RT functions return void and you know there is nothing to check.

More articles and guides are available on the technical wiki.

learn more

Need Tutorials?

Try the video tutorials and guides on Play Embedded.

learn more

Need Support?

The forums is the best place, registration required.

learn more