home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18013 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.8 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!dog.ee.lbl.gov!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: sys$hiber/sys$wake problems?
  5. Message-ID: <9211151450.AA29180@uu3.psi.com>
  6. Date: 15 Nov 92 13:27:26 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 55
  11.  
  12.  
  13.     |>    If one or more wakeup requests are issued for the process while
  14.     |>    it is not hibernating, the next hibernate call returns
  15.     |>    immediately; that is, the process does not hibernate.  ...
  16.     |>
  17.     |>This is, in fact, the correct behavior for a semaphore.  If it
  18.     |>doesn't work this way, your process could block indefinately.
  19.     |>
  20.     Hi Rob,
  21.  
  22.     And all others that responded via e-mail. You are correct,  however we
  23.     aren't the ones calling sys$wake. After leaving sys$hiber the
  24.     next-to-last time, the bit pcb$v_wakepen bit is clear. The next time
  25.     we start to enter sys$hiber it is set and we don't call sys$wake
  26.     anywhere in between. (This is what  upsets us as we hope to set up
  27.     things before calling sys$wake,  and when we don't we exit from hiber
  28.     in an unknown state). I suspect (thanks Matt) the PPL$ runtime library
  29.     as this scheme  has worked successfully for many years and PPL is the
  30.     only new  variable in the scheme. My next task is to try to trap calls
  31.     to sys$wake from the main and sharable images. Any ideas on  doing
  32.     this? I may have a hard time convicing our system manager  to let me
  33.     patch the system service vectors. Read that as slim to none. 
  34.  
  35. "Free wakes" are part of the design of the SYS$WAKE/SYS$HIBER mechanism.
  36. Since there is only one "wake pending" bit per process, not one per access
  37. level, there are tons of ways for the bit to get set.  If it was set at the
  38. rundown of the last image in the process, it is probably STILL set - rundown
  39. can't clear it, since it's not a user-mode (or any other mode) object.  If
  40. you've done any SPAWN's or ATTACH's in the process, DCL itself may have done
  41. hibernates and wakes.
  42.  
  43. Learn to live with it; that's just the way it is.  (There are good REASONS for
  44. it being that way.)  The ONLY way to use $HIBER/$WAKE reliably is in code that
  45. looks like the following:
  46.  
  47. sleep:
  48.     while (not condition)
  49.         SYS$HIBER()
  50.  
  51. wakeup:
  52.     make condition true;
  53.     SYS$WAKE(target)
  54.  
  55. Period.  End of discussion.  If you don't like it, don't use VMS.
  56.  
  57. Trapping calls to SYS$WAKE, patching system service vectors - all a load of
  58. nonsense.  If you don't like the way VMS's system services work, design
  59. another operating system; don't start mucking with VMS a bit at a time.
  60.  
  61. (Sorry to make such assertive statements, but writing reliable synchronized
  62. code is HARD.  VMS has given you a mechanism that works.  You're kidding
  63. yourself if you think it's trivial to do better.)
  64.  
  65.                             -- Jerry
  66.  
  67.