Concepts & Definitions

TheActive Object model of computation can work with a wide range of real-time kernels. Among others, event-driven Active Objects can be executed by a traditional, blocking RTOS kernel, where each Active Object runs in its own RTOS thread structured as anevent-loop. However, using a conventional, blocking RTOS to execute non-blocking Active Objects is wasteful. As demonstrated in theQK Preemptive Non-Blocking Kernel, non-blocking Active Objects can be executed more efficiently as one-shot, run-to-completion steps.

QXK Dual-Mode Kernel

QXK is a preemptive, fixed-priority, dual-mode (blocking / non-blocking) kernel that executes Active Objects like theQK kernel (basic tasks), but can also execute traditionalblocking threads (extended tasks). In this respect, QXK behaves like a conventional RTOS.

Remarks: QXK adopts the "basic/extended tasks" terms from theOSEK/AUTOSAR Operating System↑ specification[OSEK:03]. Other real-time kernels might use different terminology for similar concepts.

QXK has been explicitly designed for combining event-driven Active Objects with traditional code that requiresblocking, 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 atraditional 3rd-party RTOS (because non-blockingbasic tasks take less stack space and CPU cycles for context switch than the much heavierextended tasks). But the most significant advantage of QXK is that itprotects the application-level code from inadvertent mixing of blocking calls inside the event-driven Active Objects. Specifically, QXK "knows" the type of the task context (extended/basic) and asserts internally if a blocking call (e.g., semaphore-wait or a time-delay) is attempted in a basic task (Active Object).

Note: The QXK dual-mode kernel is significantly more complex than theQV non-preemptive kernel and theQK preemptive non-blocking kernel, and therefore it isnot recommended for safety-critical applications.

Basic Tasks

Basic tasks are one-shot, non-blocking, run-to-completion activations. The basic task can nest on the same stack. Also, context switching from a basic-task to another basic-task requires only activation of the basic-task, which is simpler and faster than full context-switch required forextended-tasks (that QXK also supports, see below).

Extended tasks

Extended tasks are endless loops allowed to block. Extended tasks require private per-task stacks, as in conventional RTOS kernels. Any switching from basic-to-extended task or extended-to-extended task requires a complete context switch.

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

QXK Blocking Mechanisms

QXK provides most blocking mechanisms found in traditional blocking RTOS kernels:

Counting Semaphores with optional timeout that can block multiple extended-tasks;
Binary Semaphores (as a subset of counting semaphores);
Blocking Event Queue with optional timeout bound to each extended-task;
Priority-Ceiling, recursiveMutexes with optional timeout;

Selective Scheduler Locking

As allpreemptive kernels, QXK requires the QP Application to be cautious with any resource sharing among Active Objects. Ideally, the Active Objects should communicate exclusively via events and otherwise shouldnot share any resources. However, at the cost of increased coupling among Active Objects, QP Application might choose to share selected resources. However, such QP Application takes the burden on itself to apply amutual exclusion mechanism while accessing any shared resources.

QXK kernel providesselective scheduler locking as a powerful mutual exclusion mechanism. Specifically, before accessing a shared resource, an Active Object canlock the QXK scheduler up to the specifiedpriority ceiling. This prevents Active Object preemption up to the specifiedpriority ceiling, while not affecting Active Objects (or interrupts) of priority higher than thepriority ceiling. After accessing the shared resource, the Active Object mustunlock the QXK scheduler.

Selective scheduling locking is anon-blocking mechanism. If an Active Object that needs to protect a shared resource is running, it means that all Active Objects of higher priority have no events to process. Consequently, simply preventing activation of higher-priority AOs that might access the resource is sufficient to guarantee the mutually exclusive access to the resource. Of course, you don't need to worry about any lower-priority AOs that might be preempted because they never resume until the current AO runs to completion.

Selective scheduler lock requests made by the same Active Objectcan nest. The nested lock requests can only increase the priority ceiling. Also, the nested lock requests must unlock the scheduler byrestoring the previous priority ceiling.

Task-Level Response

As a fullypreemptive, fixed-priority kernel, QXK always executes the highest-priority task that is ready to run (is not blocked). The scheduling algorithm used in QXK meets all the requirements of the Rate Monotonic Scheduling (a.k.a. Rate Monotonic Analysis, RMA) and can be used in hard real-time systems.

Requirements

Note: Asstated above, due to its complexity, the QXK dual-mode kernel isnot recommended for safety-critical applications. Therefore, this section contains only high-level requirements for the QXK kernel without the details needed to verify and validate QXK for functional safety.

SRS_QP_QXK_00

QP Framework shall provide preemptive non-blocking QXK kernel as one of the built-in kernels.

Description
QP Framework shall provide QXK kernel implementation and ports to the supported CPU/compiler combinations as one of the optional software components. QP Application can then choose the QXK kernel to execute Active Objects and extended tasks. Such a selection is exclusive, meaning that when QP Application selects the QXK kernel, other kernels are excluded and cannot be used.

Description
QP Framework can implement the QXK kernel component by re-using already existing mechanisms, such as event queues for Active Objects, event delivery mechanisms, event memory management, etc.