Once upon a time, I thought the world needed me to explain how to properly design and implement a state machine, preferably in C++. After jotting down a few ideas, I planned to write two articles. As luck would have it embeddedrelated was looking for authors at the time. So I decided to publish with them instead of on my blog.
As I delved into the details, I realized that two articles wouldn’t be enough to cover the entire world of Finite State Machines. In the end, I wrote four articles that were well received. Even today, years after their publication, they remain in the most popular section of the embeddedrelated website.
Fast forward a few months, and I realized that a fifth article was missing: systems composed of finite state machines. This is the synopsis:
Traditionally, complex systems are implemented using multi-threading and mutexes. Trying to scale up this approach usually results in a nightmare of data races and hidden bugs.
A single Finite State Machine may bring order to chaos in applications, but cannot be scaled beyond a limit. In this post on embedded related, I explored the Actor Model: a shift from shared state to communicating state machines. Discover how treating FSMs as independent, message-passing entities can eliminate concurrency issues, simplify testing, and improve your embedded architecture.You can read the full article here: https://www.embeddedrelated.com/showarticle/1784.php.
Coincidentally, last week—while my article was still in review—I attended the Italian C++ meetup, where Marco Arena gave a wonderful talk about Sobjectizer, an actor system and message broker framework for C++. I think his talk and the framework are the perfect complement to my article, offering a practical, hands-on approach that readers can try and experiment with. While Sobjectizer may not be suitable for resource-limited systems, the design principles behind applications developed using this framework can be translated into the embedded world.