home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.realtime
- Path: sparky!uunet!seas.gwu.edu!loew1
- From: loew1@seas.gwu.edu (Murray Loew)
- Subject: Re: Where to stick the watchdog ?
- Message-ID: <1992Sep3.180549.14429@seas.gwu.edu>
- Keywords: kernals watchdog
- Sender: Cary O'Brien
- Organization: George Washington University
- References: <1992Sep03.034229.13095@crs-sys.uucp>
- Date: Thu, 3 Sep 1992 18:05:49 GMT
- Lines: 32
-
- **** I AM NOT MURRY LOEW, DESPITE THE HEADER ***
-
- In article <1992Sep03.034229.13095@crs-sys.uucp> crs@crs-sys.UUCP (Chris Gregors) writes:
- >Recently I had an argument (discussion) with some co-workers regarding where
- >is an appropriate place to kick a watchdog timer inside an application program.
- ...
- >
- >Thoughts ? Observations ?
- >
- We had a long discussion about this a few weeks ago. Our system is
- kind of message based -- i.e. a bunch of tasks sit around on queues
- waiting for either messages or timeouts.
-
- The kernel was priority based, so a task stuck in a loop would
- block all the other tasks with lower priority.
-
- Our conclusion was that you would have to have some code in place
- to make sure that EVERY task got a chance to run within some
- reasonable length of time. I.E. there is some sort of flag that
- each task sets when it goes through it's outermost q_receive() loop,
- either because of a message or because the q_receive() timed out.
- If any task stops updating this flag for a while, then something
- is wrong and you might want to hit the panic buttom.
-
- In our case, we may even extend this to multiple processor cards --
- each card makes sure that each task is running, and some higher
- entity makes sure that each card is ok.
-
- -- cary o'brien
- -- gte spacenet
- -- c.obrien@gte.sprint.com
-
-