From: coxm@Software.Mitel.COM (Michael Cox)
Newsgroups: comp.realtime
Subject: Re: Where to stick the watchdog ?
Keywords: kernals watchdog
Date: 3 Sep 92 17:55:07 GMT
Organization: Mitel. Kanata (Ontario). Canada.


Chris,
   When we used a ROM version pre-emptive multi-tasking O/S we always stuck
the watchdog hit in the lowest priority task/process.  This task was always
the BIT (Built In Test) task/process.  Every time we ran a background test
we'd hit the watchdog.  The watchdog timers timed out from 2 to 10 seconds.
The BIT task never ran until all higher priority tasks were blocked for some
I/O (usually input to a queue/mailbox) to complete.
  Obviously without a task/process priority scheme this method won't help but
if we had, say, three tasks:  A (high priority), B (medium priority), and BIT
(lowest priority); if B goes into an infinite loop but we still have interrupts,
then A could still run but BIT could not since B would always get serviced
before BIT.
  I've seen incorrect implementations for hitting watchdogs:  from an interrupt
routine, or they're scattered throughout the code (everywhere) but these
systems didn't have an operating system; but I've also seen the watchdog hit in
the highest priority task <- not a realistic use of what the watchdog was for.
   In some cases, where large amounts of processing needed to be done and the
background BIT may not be performed for several seconds (thereby exceeding the
watchdog timeout) we purposely raised the priority of the BIT task to the same
level of the executing process (obviously this was not ADA).  That way it ran
round-robin once it's time slice was up.  In this case, after each BIT test
(and watchdog hit) was complete the BIT task re-lowered its priority back to its
normal level.  The process which would tie up the CPU was responsible for
upping the BIT processes priority when it looped in the CPU intensive area.
  In another case where the CPU was sometimes overwhelmed by a flurry of
1553 (MIL-STD) messages we had the high priority message router do two things:
i)  increment a count, and
ii) increase the priority of the BIT process to the same level as the processes
    which handled the messages.
In this case the round-robin scheduling would ensure each process at that
priority level was given a maximum equal time (quantum).  The BIT task would
decrement the count incremented by the message router (protected by a semaphore)
and when reaching zero it would reduce it's own priority back to it's normal
level.  There are several problems with this but it was a solution which worked
for this system.  One major concern with using BIT completion as the time to
hit the watchdog was that the tests performed must be set such that each
individual test must take less than a time quantum to complete.  The system
must no be too overloaded to cause the BIT process not to be run.  One nice
advantage is that if at any time the BIT fails, no messages need be sent, no
semaphores set/cleared, just don't process any more watchdog hits and
eventually the watchdog times out.
-- 
Michael H. Cox      | ". . . but there is some hope of a constitutional
                    |  settlement"  Monty Python 1971
Mitel Corporation   | "My Canada includes Alberta, B.C., P.E.I., N.S., N.B.,
                    | Ontario, Quebec, Manitoba, Sask., Yukon, Nfld, and N.W.T."
Newsgroups: comp.realtime