Choosing current APIs

This guide describes the current 0.2 development implementation. The authoritative Project status records evidence and limits; specifications describe both current mechanisms and future targets. Requirement cards marked Accepted record a design decision, not a passing implementation test.

Goal	Available now	Still planned or limited
Start and coordinate threads	Static storage, priorities, start, sleep, join/detach, cooperative cancellation	Isolated partitions, budgets, restart, SMP
Protect or signal work	Mutexes, semaphores, per-thread notifications	Event groups, condition variables, barriers
Transfer payloads	Application-owned data with an explicit synchronization protocol	Message queues, pipes, buffer pools
Run periodic work	A thread using absolute sleep deadlines	Software timers and system work queues
Wait on several readiness sources	Semaphore binding plus notification bits and rechecking	General object bindings, unbind, restart-safe target lifetime
Diagnose failures	State/priority queries, optional stack estimates, synchronous trace and fault hooks	Retained crash formats, CTF rings, full host tooling
Develop without a board	Native Linux/POSIX virtual time and conformance suite	Physical-board timing, peripheral drivers and HIL evidence
Deploy a controller platform	Embedded kernel ports and QEMU configurations	Complete board/peripheral/application integration and release qualification

The public C API reference is extracted from actual headers. Some declarations depend on configuration or link to a broader requirement than the current subset implements. Missing services are not supplied by enabling a configuration flag or copying a signature from a specification. Use Configuration to select available features and the API’s @config/@ctx contract before using it.

The first user tutorials target native development: threads and periodic work, synchronization and notifications, and debugging. They avoid assuming a driver stack, an isolated profile or a released board support guarantee. Porting an application to a physical board requires its startup, console, clock, interrupt, stack and peripheral integration to be validated separately.