QP/C  6.9.3
Real-Time Embedded Framework

Preemptive Dual-Mode (Run-to-Completion/Blocking) RTOS Kernel. More...

Collaboration diagram for QXK:


file  qpc.h
 QP/C public interface including backwards-compatibility layer.
file  qxk.h
 QXK/C (preemptive dual-mode kernel) platform-independent public interface.
file  qxthread.h
 QXK/C eXtended (blocking) thread.
file  qxk.c
 QXK preemptive dual-mode kernel core functions.
file  qxk_mutex.c
 QXMutex_init(), QXMutex_lock(), QXMutex_tryLock() and QXMutex_unlock() definitions.
file  qxk_mutex.c
 QXMutex_init(), QXMutex_lock(), QXMutex_tryLock() and QXMutex_unlock() definitions.
file  qxk_sema.c
 QXK preemptive kernel semaphore functions.
file  qxk_xthr.c
 QXK preemptive kernel extended (blocking) thread functions.
file  qxk_pkg.h
 Internal (package scope) QXK/C interface.
file  qxk/qf_port.h
 QF/C port example for QXK, generic C compiler.
file  qxk_port.h
 QXK/C port example for a generic C compiler.

Detailed Description

Preemptive Dual-Mode (Run-to-Completion/Blocking) RTOS Kernel.

QXK is a small, preemptive, priority-based, dual-mode blocking kernel that executes active objects like the QK kernel (basic threads), but can also execute traditional blocking threads (extended threads). In this respect, QXK behaves exactly like a conventional RTOS (Real-Time Operating System).

QXK has been designed specifically for mixing event-driven active objects with traditional blocking code, such as commercial middleware (TCP/IP stacks, UDP stacks, embedded file systems, etc.) or legacy software. To this end, QXK is not only more efficient than running QP on top of a traditional 3rd-party RTOS (because non-blocking basic threads take far less stack space and CPU cycles for context switch than the much heavier extended threads). But the biggest advantage of QXK is that it protects the application-level code from inadvertent mixing of blocking calls inside the event-driven active objects. Specifically, QXK "knows" the type of the thread context (extended/basic) and asserts internally if a blocking call (e.g., semaphore-wait or a time-delay) is attempted in a basic thread (active object). This is something that a QP port to a conventional 3rd-party RTOS cannot do, because such an RTOS runs all code (including active objects) in the context of havyweight extended threads.

Currently, the QXK kernel has been ported to the following CPUs:

Currently, the QXK kernel is illustrated by the following examples:

Basic Threads

QXK supports basic-threads (non-blocking, run-to-completion activations). The basic-threads all nest on the same stack (Main Stack Pointer in ARM Cortex-M), so the stack usage is reduced. The additional advantage of basic-threads is that switching from basic-thread to another basic-thread requires only activation of the basic-thread, which is much simpler and faster than full context-switch required for extended-threads that QXK also supports (see below).

QXK adopts the "basic/exteded thread" terms from the OSEK/AUTOSAR Operating System specification. Other real-time kernels might use different terminology for similar concepts. For example, the Q-Kernel uses the term "fibers", while TI-RTOS uses the term "software interrupts" for concepts closely related to "basic threads".

Extended Threads

QXK supports extended-threads (blocking, typically structrued as endless loops). The extended-threads use private per-thread stacks, as in conventional RTOS kernels. Any switching from basic-to-extended thread or extended-to-extended thread requires full context switch.

QXK is a unique dual-mode kernel on the market that supports interleaving the priorities of basic threads and extended threads. Other dual-mode kernels typically limit the priorities of basic threads to be always higher (more urgent) than any of the extended threads.
See also

Classes in QXK

The figure below shows the main classes introduced in the QXK kernel and their relation to the classes of the QP framework.

Classes of the QXK dual-mode kernel
The main takeaway from the QXK class diagram is QXK's optimal, tight integration with the QP framework. The QXK kernel reuses all mechanisms already provided in QP, thus avoiding any code duplication, inefficient layers of indirection, and additional licensing costs, which are inevitable when using 3rd-party RTOS kernels to run QP applications.

QXK Feature Summary

As you can see in the list below, QXK provides most features you might expect of a traditional blocking RTOS kernel and is recommended as the preferred RTOS kernel for QP applications that need to mix active objects with traditional blocking code.

Thread Local Storage

Thread-local storage (TLS) is a programming method that uses static or global memory local to a thread. TLS is specifically useful for writing library-type code, which is used in a multithreaded environment and needs to access per-thread data in an independent way.

TLS is used in some places where ordinary, single-threaded programs would use static or global variables, but where this would be inappropriate in multithreaded cases. An example of such situations is where library-type functions use a global variable to set an error condition (for example the global variable errno used by many functions of the C library). If errno were simply a global variable, a call of a system function on one thread may overwrite the value previously set by a call of a system function on a different thread, possibly before following code on that different thread could check for the error condition. The solution is to have errno be a variable that looks like it is global, but in fact exists once per thread—i.e., it lives in thread-local storage. A second use case would be multiple threads accumulating information into a global variable. To avoid a race condition, every access to this global variable would have to be protected by a mutual-exclusion mechanism. Alternatively, each thread might accumulate into a thread-local variable (that, by definition, cannot be read from or written to from other threads, implying that there can be no race conditions). Threads then only have to synchronize a final accumulation from their own thread-local variable into a single, truly global variable.

The TLS implementations vary, but many systems, including QXK, implement TLS by providing a pointer-sized variable thread-local. This pointer can be set to arbitrarily sized memory blocks in a thread-local manner, by allocating such a memory block (statically or dynamically) and storing the memory address of that block in the thread-local variable.

Typical usage of TLS in QXK is illustrated in the example qpc/examples/arm-cm/dpp_efm32-slstk3401a/qxk/, test.c, and consists:

See also