Hi Nathan!
Thank you for this thoughtful comment — it goes right to the core of the workshop, which was blocking and, more importantly, how to avoid it. There is a lot to unpack here, so my answer will have a few sections.

Blocking

I realized that I may not exactly know what you mean by "blocking"...

In the workshop, blocking has a very specific meaning: explicit, in‑line waiting for something to happen. This includes both:

• synchronization blocking — when a thread blocks itself by calling something like xSemaphoreTake() or xQueueReceive(), and

• mutual‑exclusion blocking — when a thread needs a resource currently held by another thread (e.g., waiting on a mutex protecting an I2C peripheral).

The key characteristic is that blocking is explicit and synchronous. You put it directly in the code (it is hard-coded): the thread stops right there and waits. In a traditional RTOS architecture, everything is handled through this kind of blocking — both synchronization and mutual exclusion. That’s exactly what I illustrated in slides 9 and 10.

This explicit blocking is very different from preemption, which is asynchronous and invisible in the code. Preemption can interrupt you at any point (when it is not explicitly disabled), but it’s not something you write or control explicitly — it’s something the preemptive scheduler does to you.

How Active Objects Eliminate Blocking

how do AOs fix that?

Active Objects allow the non-blocking architecture by enabling two strategies:

1. Active Objects strictly encapsulate resources (such as the I2C peripheral) so that only the owner AO can access the resource, which eliminates the direct sharing and any need for mutual exclusion (by blocking). This strict ownership dictates that the rest of the system can only post events to the owner AO, using it as the "server" (a.k.a., "manager" or "broker") for the resource. The "server" AO naturally serializes the access to the resource by the fact that those request events are queued and then processed to completion (RTC). I admit that I didn't explicate this in the workshop because I talked about it in every EOC before (see my previous talks "Modern Embedded Software Goes Beyond the RTOS (2020)" and "Modern Embedded Programming with Hierarchical State Machines and Active Objects", still available in the archive).

2. This leaves events as the only artifacts shared among AOs (under the deterministic "zero-copy" event exchange policy of QP). Any potential concurrency hazards around sharing events are handled (in QP) by explicit event ownership transfers, which I've spent a lot of time explaining in slides 28 and 29.

In the end, the most important idea here is ownership. Rust made ownership famous, but the concept predates Rust and can be implemented in other languages and frameworks. QP is one such example: it applies ownership both to resources (peripherals) and events (data).

Single-Event Tasks

This does seem useful, but only for tasks that need to respond to multiple events...

Tasks that wait for a "single event" are typically structured as a variant of the event loop I discussed in slide 8. Here, it's easy to conflate the blocking mechanism with the various event signals (slide 22) delivered by that mechanism.

An event loop is not limited to blocking on a message queue. Some event loops block on select(). Others block on a time delay. The defining characteristic of an event‑loop thread is that it blocks in exactly one place and never blocks while processing the event. That’s what makes it extensible.

Threads that block only on a periodic time delay are typically input‑driven state machines (slide 35). They don't need external events, but rather poll for the specific combinations of the "inputs" on each pass through the loop. This works — and is extensible — precisely because blocking is avoided inside the state machine logic. (Input‑driven state machines have their own limitations, which I briefly mentioned.)

A task that truly needs to respond to only one event (event signal) is rare. Even if it starts that way, it almost always evolves to require more events. That's the inevitable change a good architecture should anticipate and make easy.

Trace-Based Testing with QUTest

I'm similarly bummed that we didn't get to hear the end of your presentation! I was very excited to see the slides about QUTest;

I’m also sorry we didn’t get to QUTest and its trace‑based testing strategy. I was especially looking forward to showing the recent results with 100% MC/DC coverage measured using the new GCC 15.2 toolchain — some of the newer QP tests demonstrate this beautifully.

Fortunately, I covered QUTest in detail in my earlier EOC talk, “Testing of Event‑Driven Embedded Software with Python,” which is still available in the EOC archives. That session walks through the whole idea of driving automated tests from trace data, both on the host and on real hardware.

Hi Jeff,

I’m assuming that by a “runaway event generator” you mean a fault such as an unstable interrupt line or misconfigured peripheral that repeatedly triggers an ISR, which in turn posts or publishes events into the framework. When you use the regular event posting API, this condition will quickly overflow an event queue, and QP will detect the violation and assert. That assertion is your built‑in detection mechanism for this class of hardware or integration faults.

If, however, your system architecture requires tolerance to such behavior, QP provides a controlled, non‑asserting “best‑effort” delivery mode. Using the extended posting API (QACTIVE_POST_X()), you can specify a safety margin of free queue slots that must remain available. When that margin cannot be maintained, the post simply fails and the function returns false instead of triggering an assertion . The matching non‑asserting allocator (Q_NEW_X()) applies the same principle to event allocation.

This gives you a deterministic way to prevent a runaway source from destabilizing the system: events are dropped in a controlled manner, and the application can detect it and react to the failed post if needed.

At a higher level, an event‑driven system behaves no differently from a traditional RTOS‑based design in this respect. The same architectural questions apply: how do you detect a misbehaving interrupt source, how do you bound its impact, and what recovery strategy makes sense for your safety goals.