"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress .com> wrote in message news:<5IdYa.107795$JA5.2391890@news.xtra.co.nz>...
I've seen the high priority vs. low priority choice develop into a holy war.
The high-priority option will cause the WDT to trigger reset when the system
goes to pot, or the scheduler stops working properly. But it won't detect
an instance where one of the threads locks up. The low priority option will
trigger the reset in the same instances as the high priority type will, as
well as when a thread above idle blocks processing on lower priority threads.
Both options are appealing, but often a combination of the two is the best.
Set up a flag that the idle thread can use to indicate that it has executed.
Have the high priority thread check for this flag and reset it. If the
flag hasn't been set, the thread can access state information so you can
determine why the idle thread didn't execute. Then, depending on your
desired system behavior, you can toggle the watchdog or not.
This idea can be extended so that each of the threads has a bit that must
be set so the watchdog thread can verify that they've executed. By using
both a low and high priority thread for WDT handling, you gain a lot of
flexibility in the way error situations are handled.
