Ive not used a watch dog since having to code in assembly years ago. For that work code architecture was procedural and simple so i could place a watch dog timer at the end of the main loop and expect if the code never got there it was time to reset…
That said, it only seems proper that this strategy be adjusted in a Threading environment.
It would seem proper to either place a watch dog in any thread and callback where i would want to monitor, or perhaps better place a call to service the watch dog in any thread and callback i would want to monitor.
As it seems plausible to me a thread might crash while others are still executing.
Do i have this thought process correct?
A thread can exit but this is within your control. If an exception is raised then the system will also handle it depending on your code.
Watchdog runs independently, which is good. If you made a mistake in coding, or the hardware had an issue then the system will reset and continue to run.
In my code, specifically, uptime is critical and no one is perfect. the watchdog has caught a couple of times where an exception was missed and was able to fire and let the system automatically recover on its own. Obviously, in a perfect world, the watchdog will never fire because your code works 100% of the time, all the time, but even if your code is perfect, someone can plug a corrupt flash drive into your device or something external - this would throw an exception and crash your code (ask me how I know!). I treat the watchdog as the last resort - 9 times out of ten a power cycle will fix the problem, and the watchdog reset takes 4 seconds vs a 20 min manual power cycle for this particular instrument.