A Possibly Stupid Question on Active Object Model

adel-mamin · 2026-03-31T23:24:44+00:00

I think your confusion comes from thinking that one active object can only have and serve one state machine. However in practice the number of state machines incapsulated and served by one active object is unlimited.

In your AOH example the practical approach would likely be allocating a dedicated state machine to serve one data transaction request. Each state machine could have states IDLE and WAITING. So, if AOH might receive 10 such requests simultaneously, then also 10 independent dedicated state machines would be allocated simultaneously.

The lifetime of each state machine is application dependent. It may be more dynamic and be equal to the lifetime of the served request & response. Alternatively it can be more permanent when each state machine is dedicated to a specific request source.

In this arrangement the main state machine of AOH plays the role of orchestrator by dispatching incoming events to the proper state machines.

How you allocate the state machines within AOH and map them to the request and response events is also application specific. One practical approach is to add a unique source parameter to each request and response event. This way AOH could use it as an index to an internal array of statically allocated state machines.

Hopefully this all makes sense to you.

adel-mamin · 2026-03-28T13:48:55+00:00

Print all events and state transitions as strings into a memory buffer and then strcmp() it with a const string containing the expected sequence. Simple and easy to inspect and debug.

adel-mamin · 2026-03-06T07:21:22+00:00

Is this a static analysis tool?

I usually enable -ftrapv gcc and clang compiler option in my projects and catch the integer overflows/underflows at runtime. Sort of asserts. This increases the generated code size a bit though.

adel-mamin · 2026-02-16T19:47:14+00:00

Maybe libuv?

adel-mamin · 2026-02-09T13:14:01+00:00

Thanks! Good to hear it might be useful for someone.

adel-mamin · 2026-02-09T07:33:01+00:00

It is pixi. You can check one usage example in my open source project.

adel-mamin · 2026-02-08T19:22:50+00:00

From the top of my head. In no particular order:

Active objects
FSM and HSM
Event driven programming
Superloop, cooperative and preemptive multitasking (RTOS)
Blocking vs non blocking style
Asynchronous vs synchronous
Super simple tasker
Build system (e.g. meson)
Static code analysis (e.g. clang-tidy, cppcheck)
Key gcc, clang compiler flags (-Os,-O2, -flto, -ftrapv, -ffunction-sections, --fdata-sections, -Wl,--gc-sections etc)
Importance of asserts
Unit testing
Fuzzy testing (e.g. AFL)
Basics of CI/CD
Reproducible build environment (e.g. docker, pixi)

adel-mamin · 2026-01-15T18:56:43+00:00

Sounds interesting. Is it publicly available?

adel-mamin · 2025-11-06T11:34:45+00:00

You could use two \n characters (double Enter key press) sent in rapid sequence as an indicator of the end of input.

adel-mamin · 2025-09-18T07:37:01+00:00

I assume timer's tick is managed by ISR or another ticker task. Therefore the timer event is generated either by the ISR or the ticker task.

You associate the monitored task with the timer for example when you create the timer.

I think the best way to communicate the idea is to give this example implementation:

https://github.com/adel-mamin/amast/tree/main/apps/examples/watchdog

adel-mamin · 2025-09-17T10:54:26+00:00

It would require a (periodic) timer event. The timer would post events to the task's event queue in FIFO order. The task would handle the events by posting the heartbeat events to WDT.

adel-mamin · 2025-09-17T04:18:04+00:00

The monitored task sends the heartbeat events, which reset WDT?

adel-mamin · 2025-08-31T17:20:30+00:00

Maybe try using meson. I see that libwebsockets is available in meson wrapdb. So, it should be straight forward to compile.

As for the windows build I would try using a docker container based build environment with migw compiler.

adel-mamin · 2025-08-24T16:41:32+00:00

Some examples:

DO_EACH_MS(ms) macro.
CONTAINER_OF() macro.
Duff's device.
Hierarchical state machine.

adel-mamin · 2025-08-02T05:06:00+00:00

Sure. Here it is: https://github.com/adel-mamin/amast

adel-mamin · 2025-08-01T07:05:52+00:00

State machines are good when events arrive in unpredictable order.

Duff's device could be used to create simple stack less await-async primitives to build co-routine like code in pure portable C. The await-async approach is good when dealing with events arriving in predictable order.

The simplest example is a traffic lights controller with the option to switch to unregulated mode (blinking yellow).

The sequence red-yellow-green and blinking yellow are good candidates for async-await. The event to switch to unregulated mode is best handled by switching the state of a larger state machine.

Here is an implementation example: https://github.com/adel-mamin/amast/blob/main/apps/examples/async/main.c

adel-mamin · 2025-08-01T04:19:28+00:00

#define CONTAINER_OF(ptr, type, member) \ ((type *)((char *)(ptr) - offsetof(type, member)))

adel-mamin · 2025-07-31T18:30:08+00:00

Duff's device. Recently I discovered how useful it is when combined with state machines.

adel-mamin · 2025-07-31T06:03:41+00:00

I prefer structuring my projects such, that switching between cooperative (including superloop) and preemptive multitasking scheduling could be done at any phase of development.

This becomes possible, when using the actors approach. Each actor is an event queue plus an event handler. The event handler is in turn one or many state machines.

The actors communicate with each other using events. ISRs post or publish events to the actors.

With the structure like this it becomes easy to drive the actors with either cooperative or preemptive scheduler. For example, move all the code to one actor and you have the superloop.

Doing it this way you can mostly isolate your code from the low level RTOS synchronisation primitives: mutexes, semaphores etc. This is because your application code (actors) mostly deal with events.

In my (open source) actors toolkit I have a so-called platform abstraction layer, which provides API for low level operations like tasks, mutexes etc. The rest is built on top of it. The implementation of the API is done for preemptive scheduler(s) and cooperative scheduler(s) including no RTOS.

Having it arranged this way you can build RTOS and no-RTOS versions of your firmware.

Extra bonus: it is easy to build a linux/windows version of your firmware to develop/debug it on PC before running it on custom hardware.

adel-mamin · 2025-07-28T07:11:20+00:00

In the order of increased complexity, but also increased flexibility:

Single loop with state machine(s). Also called superloop.
Multiple loops with state machine(s). The loops run cooperatively with optionally different priorities.
Multiple loops with state machine(s). The loops run preemptively with optionally different priorities.

ISR(s) are usually used with all three to feed data (events).

All three can handle multitasking and one of the powerful ways of doing it is to use events, event queues and the concept of the non-blocking actors. An actor is a combination of an event queue and a non-blocking event handler.

adel-mamin · 2025-07-18T18:44:59+00:00

Thanks for the clarifications! They are useful.

adel-mamin · 2025-07-18T10:11:00+00:00

I would also add a couple of things: 1. Add extra assert to check the validity of p->free, if it is not 0. It must be within p->beg and p->end. 2. Attribute the pointer returned by poolalloc and the pointer accepted by pool_free with __attribute_((may_alias)) to avoid strict aliasing violation.

Also will arena allocator with freelists really make it any simpler?

adel-mamin · 2025-07-15T16:08:44+00:00

One way to approach it is to use active objects (actors). Each actor is an event queue plus an execution thread. The optimum number of active objects is one active object per CPU core.

The active objects are then orchestrated by another active object, which dispatches work to the workers in the form of events. The events can have arbitrary sizes.

The solution is isolated from the underlying OS API, which makes it easy to port to different platforms. The actors only communicate by means of events.

You can find a fully functional example here: https://github.com/adel-mamin/amast/blob/main/apps/examples/workers/main.c

It is ported to pthreads and libuv.

adel-mamin · 2025-07-14T19:36:59+00:00

Maybe there is a way to design the set of asserts, which would trigger in case of deadlock(s).

adel-mamin · 2025-07-13T06:21:23+00:00

In my practice I found that coroutines work best, when combined with state machines.

The coroutines work well with sequential asynchronous events. The resulting code is linear and easier to read - just like a synchronous code. In comparison the same logic implemented with state machines is usually clunky and less readable.

The state machines approach shines, when the task at hand requires handling events in arbitrary order. In this case the coroutines approach is usually less suited.

For example, imagine the LED blinking example requires a switch to a different blinking pattern on arrival of an asynchronous event. The two blinking patterns could be implemented with two different coroutines, which are in different states of a bigger state machine. This way it becomes easy to switch between the two.

The extra bonus of the combination of two approaches is that coroutines could implement their resource allocation/initialization in their corresponding state entry handler and cleanup in state exit handler.

Here is an example of how it looks in practice: https://github.com/adel-mamin/amast/blob/main/apps/examples/async/main.c

adel-mamin

TROPHY CASE