Too little else to do

By the way, I don't understand the rationale for the term "kicking the dog" to reset its downgoing counter, so that it's again long before it would reach zero. Should we anthropomorphise, then "feeding the dog" should serve better. In particular, for such a nice dog as is used in the figure, namely the Windows operating system's "search dog".

Here, the problem was process P0. It was burning EEPROM, one "sector" at a time, and then descheduled itself with no timeout by returning back to the non-preemptive run-time system's  FSM_Scheduler - which immediately rescheduled P0.

See "From message queue to ready queue" about RQue and the synchronous channel communication layer

Our solution was to insert a short (1 ms) delay in P0, thus making RQue empty provided the system had nothing else to do. We could have "yielded" instead, so that FSM_Scheduler would have returned even if RQue was not empty. In any case, the FSM_Drivers would now also run - to pick up lower level timer and i/o stuff.

The solution involved no tuning with priority (we have no such, neither on processes nor messages). No tuning with extra inserts of kick_dog calls, as we try to avoid spreading them. We were, however, able to find a solution without side effects - to keep the self-monitoring embedded system up and running.