Can an RTOS be really real-time?
Real-Time Operating Systems are meant for real-time applications. But with conventional shared-state concurrency and blocking, can you honestly know the worst-case execution time of an RTOS thread?
Summary
Miro Samek challenges the assumption that RTOS-based threads are inherently real-time, examining how shared-state concurrency and blocking obscure worst-case execution time (WCET). The blog explains why conventional RTOS primitives can invalidate timing guarantees and outlines design patterns and analysis steps to make thread timing provable.
Key Takeaways
- Identify common sources of non-determinism in RTOS systems (blocking calls, shared locks, dynamic memory, and priority inversion).
- Measure and bound worst-case execution time (WCET) by isolating interrupt paths, constraining execution regions, and eliminating unbounded primitives.
- Prefer message-passing, non-blocking designs, and priority-aware synchronization to minimize hidden latencies.
- Design and apply system-level analysis (response-time analysis, admission control, and timing budgets) to prove deadlines under realistic load.
Who Should Read This
Experienced embedded firmware engineers and system architects building latency-sensitive or safety-critical systems who need to understand and prove RTOS timing behavior.
TimelessAdvanced
Related Documents
- Consistent Overhead Byte Stuffing TimelessIntermediate
- PID Without a PhD TimelessIntermediate
- Introduction to Embedded Systems - A Cyber-Physical Systems Approach Still RelevantIntermediate
- Memory Mapped I/O in C TimelessIntermediate
- Design and Implementation of the lwIP Stack Still RelevantAdvanced









