runtime thread execution monitoring (identify cause of hung code)

[Todd]

The method that a lot of embedded systems watchdogs I've come across is the following:

High priority task maintains a collection of bits for other periodic tasks.

High priority task (at the rate that other tasks are expected to run) sets bits false.

Other tasks set the bits true when they run.

If the High priority task, when it goes to set the bits notices that they haven't been flipped back, then it knows that the low priority task has not run in that timeframe.

Once it realizes that a certain number of frames have passed without the other task 'reporting in', it knows something is wrong. You don't really need mutual exclusivity or interrupts to maintain this, so long as you can ensure that the 'task monitor' thread is of elevated priority.

There's no metrics available on 'how much' of the other tasks available cycle was consumed before it was completed, but that could be added fairly trivially.

I work with several systems like this, if the 'tried and true' notion is of any value.