RK0

1. Introduction

Real-time kernels are frequently presented as a set of primitives: semaphores, queues, mutexes, event flags, timers, and notifications. Normally, they are generic enough and sometimes overloaded.

RK0 adopts a different premise. Coordination dependencies should be explicitly represented in a manner that can influence blocking, wakeup, effective priority, timeout handling, or dispatch. The central design guideline in RK0 is that a kernel service is valuable when it exposes a dependency that the kernel must account for to manage worst-case behaviour.

The application programmer declares the coordination dependency, and the kernel manages the resulting priority-relevant consequences. This core design principle is developed in the following sections.

2. Generic Primitives and Semantic Displacement

Real-time kernels frequently provide broad, generic primitives, requiring application code to assemble the intended protocol. While this approach maximises flexibility, it also introduces hidden assumptions. For example, a full queue may indicate backpressure on a single receiver, a locked mutex may imply nested ownership with transitive priority effects, a request queue may represent a client blocked behind a server, and a delay may signify either simple suspension or a periodic release relationship.

The issue is not an absence of semantics in these primitives, but rather that their semantics may be insufficiently aligned with the real-time dependencies they are intended to express. Consequently, meaning is displaced into application code, where it becomes implicit, dependent on conventions, and more susceptible to fragility during maintenance.

This phenomenon is what we refer to as semantic displacement: the migration of scheduler-relevant meaning from kernel services to application conventions.

3. Explicit Coordination Dependencies

RK0 uses the term ‘semantic’ in an operational sense. A service is considered semantic when its semantics can influence blocking, wakeup, effective priority, timeout handling, freshness, temporal release, or dispatch.

This consideration goes beyond improved naming; it constitutes a runtime design criterion. The programmer does not merely choose among interchangeable primitives. The programmer states the dependency, and the kernel takes responsibility for the worst scheduling cases that result from it.

4. Execution Model and Emergent Time

An emergent property in a software artefact is the result of the interaction between individual units of that artefact, but that is not itself present in any of the units. Arguably, in real-time systems, the runtime behaviour emerges from implementation. 

RK0 does not eliminate such emergence; instead, it facilitates identification and reasoning about these sources by maintaining a simple kernel model and explicit service contracts. It starts off with a simple execution model. 

RK0 uses a standard fixed-priority preemptive scheduler. The scheduler dispatches the highest priority READY task. No built-in time-slice feature exists; same-priority tasks cooperate explicitly by yielding, blocking, or waiting. As a result, progress occurs for explicitly stated reasons.

The resulting invariant is clear: a task executes because it is the highest priority READY task under the current effective priority relation. Services may make tasks READY, block them, wake them, or alter effective priority through dependency rules; however, dispatch remains the responsibility of the scheduler. Services express coordination, while the scheduler manages execution progress.

This separation is significant because it keeps worst-case reasoning close to the actual causes of delay. 

5. Software-Engineering Perspective

From a software engineering perspective, RK0 addresses the appropriate location for real-time meaning. Instead of relying on application-level conventions for coordination semantics, it seeks to encapsulate recurring scheduling dependencies in explicit service contracts.

This has several consequences.

Quality	RK0 interpretation	Practical effect
Cohesion	Each non-core service captures one coordination responsibility	Services can be understood and reviewed by contract
Context-stable semantics	Service meaning does not drift by local convention	Less reliance on hidden protocol
Composability	Services compose through visible dependency effects	Larger coordination structures remain analysable
Analysability	Blocking and priority effects follow from the chosen service	Easier reasoning about who waits for whom and why
Worst-case orientation	Kernel handles pathological scheduling cases	Timeout removal, inversion, freshness, drift, and backpressure become first-class
Commonality / variability separation	Hardware and application vary; dependency side effects recur	The service model remains reusable across domains

The relevant metric is not limited to runtime cost, but also includes reasoning cost: the extent to which hidden conventions must be reconstructed by the reader to understand why a task may block, wake, inherit priority, or drift.

6. Service Map by Dependency Type

RK0 services function as runtime dependency contracts. Each service provides the scheduler with visibility into a distinct recurrent cause of blocking/progressing.

6.1 Priority inversion is a dependency problem

Priority inversion is not simply a mutex implementation detail; it is a consequence of ownership. When a high-priority task waits on a mutex owned by a lower-priority task, the scheduler must be aware of this relationship. If ownership is nested, the relationship must propagate throughout the chain. If a waiter times out or a lock is released, effective priority must be recomputed accordingly.

6.2 Backpressure is not simply a buffer state

In a bound queue, a full buffer does not just indicate fullness. It can signify that a high priority producer is blocked until a specific receiver executes and creates space. When the queue is owner-oriented, this association becomes visible to the scheduler. The receiver is not simply draining a buffer, it is the task whose progress allows the progress of another task.

6.3 Invocation is different from transfer

A synchronous request/reply interaction can be constructed from queues and semaphores, however, such an assembly does not necessarily expose the caller-server dependency to the scheduler. A call channel, however, makes this link explicit. The server is not simply receiving data, it is executing on behalf of a blocked caller.

6.4 Freshness is different from history

A FIFO queue preserves message history, while MRM preserves the latest valid state. These stands for distinct contracts. In many real-time systems, stale state is not valuable only because it arrived earlier; the most recent valid state is what matters. 

6.5 Periodic tasks can overrun, handling cannot be the same 

A generic sleep function merely specifies that a task should not execute for a given interval. Real-time periodic execution often requires a more robust contract, such as preserving phase, maintaining local periodicity, or accounting for skipped releases. Differentiating these timing semantics prevents periodic work from drifting unnoticed.

The RK0 docbook has examples for each of these cases.

9. Conclusion

RK0 is most accurately described as a real-time kernel design centred on explicit coordination dependency. Its services are semantic not only because of their narrow scope, but also because their meanings are operational: they expose runtime dependencies that influence blocking, wakeup, effective priority, freshness, timeout handling, temporal release, and dispatch.

The key engineering move is the division of responsibility. The application programmer declares the dependency. The kernel manages the worst scheduling consequences that follow from that dependency.

The reusable unit pursued by RK0 is therefore not the device, the driver, or the application pattern. It is the recurring real-time side effect of one task depending on another.