home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / realtime / 1046 < prev    next >
Encoding:
Text File  |  1992-09-03  |  1.6 KB  |  45 lines

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