Interrupt Handling and Synchronization

The criterion. RTOS environments must respond to hardware events instantly: low, bounded interrupt latency; a way to defer heavy work out of hard ISRs; and priority-inversion mitigation (priority inheritance or ceiling).

How Revera answers it

On every MCU port the kernel tick and the context switch run off real interrupts (e.g. ARM SysTick → PendSV, RISC-V machine-trap), so scheduling is preemptive — a higher-priority thread woken in an ISR runs as soon as the ISR returns. Deferred processing is the natural idiom: an ISR does the minimum, then wakes a thread with tk_sem_post / tk_cond_signal (safe from ISR context), and the heavy work runs at thread priority. Priority inversion is handled by priority inheritance on mutexes, on by default.

Feature · how to turn it on · how to use it · where it works

Feature

Turn on with

Use these APIs

Where

Priority inheritance (single-level)

default (TK_MUTEX_PRIO_INHERIT)

tk_mutexattr_setprotocol, then tk_mutex_lock / unlock

all

Deferred (bottom-half) processing

—

tk_sem_post / tk_cond_signal from an ISR → wakes a thread

all

Preemptive switch from an ISR

default

(tick → PendSV / trap; automatic)

preemptive ports

Idle / stall observation

—

tk_kernel_set_idle_hook, tk_kernel_on_stall (weak hook)

all

Full signatures and contracts: API reference — Synchronization / Threads.

Limits & roadmap

  • Interrupt-latency numbers are not published — latency is an arch + board + interrupt-controller property; measure it on your target.

  • Priority-inversion mitigation is priority inheritance only (single-level); there is no priority-ceiling protocol.

  • Revera does not impose a portable ISR framework — ISRs are arch/board code; the kernel gives you the wake-a-thread and trace-hook seams, not a driver-model interrupt abstraction.

Learn more