Zephyr Deadline Scheduling: Understand the Static-Priority Boundary
Zephyr’s deadline option orders eligible threads within the same static-priority class. It does not allow a lower-static-priority thread to outrank a higher-static-priority thread merely because its deadline is earlier. Validate that boundary before using the option to express a product-wide urgency policy.
This guide targets Zephyr v3.7.0 with CONFIG_SCHED_DEADLINE enabled, one CPU, ordinary preemptible threads and no meta-IRQ threads. It considers scheduler selection among ready threads. Cooperative execution, scheduler locking, SMP and hardware interrupt interference require additional analysis. No target scheduling test or hard real-time guarantee is claimed.
Write the ordering rule before choosing priorities
The versioned scheduling documentation places static priority first and deadline ordering within equal static priorities. The deadline-setting API states the same restriction and explicitly disclaims a guarantee that the thread will execute by its deadline.
For each workload, distinguish static priority class, ready state, deadline value and execution demand. A thread that is blocked on a device is not selected simply because its deadline is urgent. A thread that needs more execution than the available capacity cannot gain that capacity from an earlier deadline label.
| Controlled ready set | Selection principle | Design consequence |
|---|---|---|
| Different static priorities | Higher static priority wins | Earlier lower-class deadline does not cross the boundary |
| Equal static priority, different valid deadlines | Earlier deadline orders the choice | Comparable jobs must share a class if this ordering is intended |
| Equal priority and equal deadlines | Ordinary equal-priority ordering remains relevant | Do not invent a further urgency ranking |
| Earlier-deadline thread is unready | It is not an eligible ready candidate | Deadline metadata does not complete a wait |
Do not collapse all work into one static priority just to make the deadline field influential. That is a scheduling redesign with consequences for dependencies, critical services and overload. Start from the required service classes and explain which work should compete within each one.
Interpret the API’s units and comparison window correctly
k_thread_deadline_set() takes a relative delta in the units used by k_cycle_get_32(), not milliseconds or scheduler ticks. Record the clock basis and conversion in the build under review. A numeric value copied from a millisecond configuration can encode a very different interval.
The 3.7.0 API documents 32-bit internal deadline storage and requires the span between the first and last queued deadlines to remain below 231 cycles. That is a queue-wide comparison-window obligation, not simply a reason to check each input in isolation. Do not assume that a series of individually plausible relative deadlines can remain comparable indefinitely without managing stale values.
The tagged setter implementation updates the deadline and requeues a queued thread to preserve ordering. Keep validation and error policy in the wrapper; do not depend on implementation clamping to correct an application unit mistake. The call is not a release timer or a job-cancellation mechanism, and its name does not promise immediate completion or deadline enforcement.
Check the backend and effective configuration
The v3.7.0 scheduler configuration makes the traditional multi-queue backend incompatible with deadline scheduling. Verify the effective generated configuration and selected backend rather than assuming a copied configuration fragment took effect.
Record whether application code changes static priorities after initialization and whether wrappers change deadlines for each job. Include units, valid horizon, stale-job policy and the point at which a job becomes ready. These details explain what the scheduler can actually compare.
Construct counterexamples to the proposed policy
- Cross-class case: prepare two ready threads with different static priorities. Give the lower-priority thread the earlier deadline. At a controlled scheduling point, verify that static priority still determines the selected class.
- Within-class case: use equal static priorities and distinct deadlines inside the documented comparison window. Verify the earlier-deadline ordering under the same controlled conditions.
- Readiness case: block the earlier-deadline thread on an unavailable object. Verify that its metadata alone does not make it runnable.
- Overload case: admit more bounded work than the available service budget can satisfy. Require the application’s missed-deadline policy to activate instead of assuming the kernel rejects infeasible demand.
- Unit and horizon rejection: exercise invalid conversion, excessively distant deadlines and stale queued work in the application wrapper.
These are proposed target tests. Use a gate to establish the ready set before the observation and retain the exact configuration. Uncontrolled creation order can otherwise make a trace look like a deadline comparison when only one candidate was ready.
Separate the selection result from response time. Even a correctly selected thread can be delayed by interrupts or consume more time than expected. Record release, ready, first execution and completion separately only where those measurements are actually collected.
Hypothetical example: a short display deadline cannot outrank acquisition
Imagine a hypothetical device with acquisition in a higher static-priority class and display rendering in a lower one. The display assigns an earlier deadline because an animation frame is due, then expects to preempt acquisition. That expectation contradicts the class boundary even if both deadline values are well formed.
The team must decide whether acquisition should retain class-level precedence or whether specific jobs should compete within a common class. If it changes the design, it must analyze execution demand and shared resources rather than treating a deadline setter as an automatic feasibility check.
Deliver an enforceable application contract
Keep a class/deadline ordering table, valid-unit conversion, queue-wide horizon rule, ready-state assumptions and overload response with the firmware. Reject designs whose required cross-class preemption is absent from the actual scheduler contract. Recheck after changing the backend, static priorities or clock configuration.
The acceptance result is a demonstrated ordering under stated conditions plus an application policy for missed work. It is not a claim that enabling the deadline option proves schedulability or turns every relative deadline into an enforced completion bound.
