By Miro Samek – An RTOS (Real-Time Operating System) is the most universally accepted way of designing and implementing embedded software. It is the most sought after component of any system that outgrows the venerable “superloop.”
But it is also the design strategy that implies a certain programming paradigm, which leads to particularly brittle designs that often work only by chance. I’m talking about sequential programming based on blocking.
Blocking occurs any time you wait explicitly in-line for something to happen. All RTOSes provide an assortment of blocking mechanisms, such as time-delays, semaphores, event-flags, mailboxes, message queues, and so on. Every RTOS thread, structured as an endless loop, must use at least one such blocking mechanism, or else it will take all the CPU cycles. Typically, however, threads block not in just one place in the endless loop, but in many places scattered throughout various functions called from the thread routine.
This excessive blocking is evil, because it appears to work initially, but almost always degenerates into a unmanageable mess. The problem is that while a thread is blocked, the thread is not doing any other work and is not responsive to other events. Such a thread cannot be easily extended to handle new events, not just because the system is unresponsive, but mostly due to the fact that the whole structure of the code past the blocking call is designed to handle only the event that it was explicitly waiting for. more> https://goo.gl/k7OPPc