"In my projects, I often implement what are effectively tasks using a home-grown operating system. I need to ensure that none of these tasks nor the main thread of exectution get stuck."

You use an OS, the result being that you need a watchdog to reset when things go wrong. This seems a bit like saying 'I've added another layer of complexity to the software and a reset button to fix it when it goes wrong'. Or am I just being cynical?

Otherwise, I think your watchdog implementation is about as good as such things can get.

I'm going to stick my head above the parapet now and say:

Watchdogs are bad.

1) They encourage sloppy programming. 'Oh well, I'm pretty sure that code is good. I won't bother giving it another five minutes thought because the watchdog will reset on the off chance things go wrong'.

2) They are a potential bug. In a large or complex program it can be extremely difficult to time profile all possible paths of execution to ensure the watchdog is strobed frequently enough.

3) They are a maintenance nightmare. Every time the code is modified see (2).

4) They are falsely seen as program validators. 'The system works great, the watchdog never resets'. What about the logical errors?

5) The watchdog implementation itself is a non-trivial task. What percentage of 8051 programmers are sufficiently skilled to make a decent job of it? A poorly implemented watchdog scheme is worse than useless.