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

[@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!

[@AdityaKumar-xw2yx]

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

[@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, kzbin.info/www/bejne/oZTTh3xpfs-Ii68si=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 :)

[@กฤชพลเกตุชู]

Very good recourse.

[@drojf]

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

[@kagha8240]

Great video .

[@nolimangulabnan6101]

You are like God to 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