RK0

The design take

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. Services are shaped (from internals to API), so they explicitly express how they impact runtime progress.

The application programmer declares the coordination dependency, and the kernel manages the resulting priority-relevant consequences.

RK0 architecture has at least three views:

• The Real-Time Execution and Communication Model defines the relations between tasks, kernel objects and data abstractions as Event, Signal, Message
• The Service Map that explains service semantics, its pre/post conditions and side-effects
• The Structural View that provides a logical layering of functional units, divided as ‘Executive’ and ‘Low-Level Scheduler’ – or policies and mechanisms

This information is on the Wiki and Docbook

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.

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.

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.

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.

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.

The real deal

The key engineering move is to frame the design around dependencies that arise at runtime, rather than on overly generic primitives. The underlying real-time model was designed to enable application programmers to specify when, why, and how execution should progress. The API embodies stable contracts for cohesive services that, in turn, are optimised for worst-case scenarios and time-bounded.