Beyond the RTOS - Part 2: Best practices of concurrent programming and Active Object pattern

This is part-2 of the talk "Modern Embedded Software Goes Beyond the RTOS" that Miro Samek presented at the [Embedded Online Conference in May 2020](www.embeddedonlineconference.....
This part explains the best practices of concurrent programming and the "Active Object" design pattern.
The next part will show how to implement active objects on top of FreeRTOS
End Notes:
----------
Active Object design pattern:
www.state-machine.com/active-...
Music credits:
The background music comes from:
www.bensound.com/royalty-free...

[@AdityaKumar-xw2yx]

Sometime , I feel we should have libery to give 100 or 1000 likes, specially for this type of tuturial. Bow!!

[@lemon6521]

Oh man I just started your embedded playlist and I had no clue you were still making videos! I have a heck of a backlog but I'm super excited to watch this once I feel caught up, as well as whatever else you make in the meantime. Thank you for teaching us!

[@user-to3ll9jm4l]

Very good recourse.

[@kagha8240]

Great video .

[@drojf]

I was about to say "isn't this similar to the Actor model", but you did mention it at the end.

[@nolimangulabnan6101]

You are like God to me 😆

[@LazaLazic-wq3ce]

Is the event queue in an active object considered a shared resource? Do we need to protect access to prevent race conditions, or is it implemented differently?

[@StateMachineCOM]

I'm really glad that you asked because it shows that you're already questioning everything that looks like *sharing* of resources! So, yes, of course! Event queues of active objects *are* obviously shared and not just among other active objects but also among ISRs that might be posting events to the queues. So, aboslutely: the queues, as any shared resources, need to be protected. The protection is typically accomplished by criticial sections (briefly disabling interrupts) strategically placed inside the queue API. This is also how most RTOSes protect all their mechanisms, such as message queues, semaphores, mutextes, etc. I discussed mutual exclusion (including critical sections) in lesson #28 RTOS Part-7, ruclips.net/video/kcpVI3IjUUM/видео.htmlsi=iylXR7_sSpdLa3F7 ) --MMS

[@LazaLazic-wq3ce]

@@StateMachineCOM Thank you so much for clarifying that! I must admit, terminology like 'private queue' and the 'shared nothing principle' initially threw me for a loop. Taking those terms literally, I started to question everything and reevaluate. Your explanation was a lightbulb moment for me :)

[@iwasz]

Correct me if I'm wrong : ActionObject_dispatch should not block on any RTOS primitive like semaphore, queue or delay, but it can "block" if an algorithm it runs takes time to finish right? What would be the point of threads otherwise?

[@StateMachineCOM]

An active object should *not* block internally, period. If an algorithm calls for a delay, then you should use a Time Event. This was exactly the case with the Blinky thread in the presentation, where the traditional sequential algorithm required a (blocking) delay. As you saw in the non-blocking solution a time event not only worked perfectly, but was superior, because the thread remained *responsive* to any other events. In the end, this is exactly what I mean by the *paradigm shift* from sequential way of thinking based on blocking and event-driven way of thinking based on events. If my arguments did not convince you, perhaps you will prefer an article by another author "Managing Concurrency in Complex Embedded Systems" by Dr. David Cummings ( www.state-machine.com/doc/Cummings2006.pdf ). --MMS