Every few years an RTOS vendor rediscovers the fact that developers are tired of creating multiple tasks just to handle multiple events. The latest example that I found in my inbox today is the SAFERTOS article on Event Multiplexing, which acknowledges the problem:
“Tired of creating multiple tasks just to handle multiple events? In real-time systems, waiting on more than one condition, such as queue space and a released mutex, can quickly lead to wasted CPU cycles and bloated designs.”
This is not a SAFERTOS‑specific issue — every traditional RTOS runs into the same technical debt. Every task, sooner or later, discovers the need to wait on more than one condition. At this point, developers start inventing workarounds: extra tasks, extra queues, extra semaphores, or now, “event multiplexers.”
But here’s the important part that RTOS vendors rarely say out loud:
1. Traditional RTOSes fully recognize the need to handle multiple events in one task.
They know that hard-coded event sequences (as the blocking calls in the task loop) are inflexible. They know developers end up with task explosion, wasted RAM, and unnecessary context switching.
2. They also recognize that developers are exhausted from creating tasks just to block on different objects.
The SAFERTOS article even says it directly: developers are “tired” of this pattern. And they should be — it’s a symptom of a deeper architectural mismatch.
3. The only real way out is to reduce blocking and move toward an event‑driven model.
Event Multiplexing is presented as a convenience feature, but look closely at what it quietly recommends you to do:
- A single blocking call at the top (the event-multiplexing in this case, but often also a message queue, event-flags, the select system call, or time-delay for periodic execution).
- Followed by strictly non‑blocking event processing in the loop body.
- With all event sources funneled into a unified dispatch path.
This is not an RTOS invention. This is the event‑loop architecture — the same structure concurrency experts have recommended for decades.
And it is, of course, the foundation of the Active Object model.
What RTOS vendors don’t tell you
RTOS documentation usually stops at the “multiplexing” trick — how to combine multiple blocking mechanisms into one consolidated wait at the top of the task’s loop. But they never discuss what happens after that wait returns.
Why? Because once you pass that single blocking point, the RTOS becomes irrelevant.
Everything downstream must be:
- non‑blocking
- run‑to‑completion
- event‑driven
- free of mutexes, semaphores, and other blocking primitives
In other words, the RTOS cannot help you with the part of the architecture that actually matters. In fact, it often gets in the way.
Traditional RTOSes are built around blocking. Event‑driven systems are built around not blocking. These two programming paradigms do not mix cleanly.
Beyond the RTOS
When an RTOS introduces “Event Multiplexing,” it is quietly admitting:
- Blocking is the root cause of task proliferation.
- Task loops should consist of a single, “multiplexed” wait point followed by non-blocking event-processing code (event-loop).
- The architecture is drifting toward Active Objects whether the RTOS likes it or not.
- The RTOS is not helpful in the most difficult part of the problem, which is how to actually process the events without blocking.
In other words, the RTOS cannot help you with the part of the architecture that actually matters. In fact, it often gets in the way.
If you would like to learn more about the missing piece, please watch the “Beyond the RTOS” videos.