home *** CD-ROM | disk | FTP | other *** search
/ ftp.cse.unsw.edu.au / 2014.06.ftp.cse.unsw.edu.au.tar / ftp.cse.unsw.edu.au / pub / doc / misc / apollo / ost-mutex-locks < prev    next >
Encoding:
Internet Message Format  |  1992-10-18  |  3.8 KB

  1. Path: usage.csd.unsw.oz.au!metro!munnari.oz.au!samsung!mips!swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!pisa.citi.umich.edu!rees
  2. From: rees@pisa.citi.umich.edu (Jim Rees)
  3. Newsgroups: comp.sys.apollo
  4. Subject: Re: DN4500 arbitrarily overloads itself (was Re: (none))
  5. Message-ID: <52629c2f.1bc5b@pisa.citi.umich.edu>
  6. Date: 25 Jun 91 16:50:54 GMT
  7. References: <0677436884@INESCN.RCCN.PT> <DPASSAGE.91Jun20122344@soda.berkeley.edu> <1991Jun24.002623.18899@gtephx.UUCP>
  8. Sender: usenet@terminator.cc.umich.edu (usenet news)
  9. Reply-To: rees@citi.umich.edu (Jim Rees)
  10. Organization: University of Michigan IFS Project
  11. Lines: 63
  12.  
  13. In article <1991Jun24.002623.18899@gtephx.UUCP>, wilsonj@gtephx.UUCP (Jay Wilson) writes:
  14.  
  15.   I saw this posting and I could not resist having one of my partners
  16.   in crime (there are 6 of us Sys_admins) respond to it.  He has been tracking
  17.   the Mutex Lock problem for over a year now and this is what he had to say.
  18.  
  19.   ...
  20.  
  21.   The error will rear its ugly head with no warning or pattern,
  22.   and once you get it you MUST reboot and run the long SALVOL
  23.   to appease its appetite for disaster.
  24.  
  25. I find this hard to believe.  I've never had to run a long salvol after
  26. getting a stuck sfcb mutex, and I can't think of anything that a long salvol
  27. might do that would fix it.
  28.  
  29.   If you would like more information on exactly what "sfcb hash table" and
  30.   "mutex lock" are, please refer to a copy of the "Domain/OS Design Principles"
  31.   014962-A00 pages 9-14,9-15.
  32.  
  33. That paper was also published in the Atlanta Usenix Proceedings, which I
  34. think was summer 1986.  It's also available by ftp from pisa.citi.umich.edu.
  35. I think it's an excellent paper and everyone should read it.
  36.  
  37. The basic problem with putting mutex locks in shared memory is that any old
  38. program can go and trash them, and then you're stuck.  What's needed is a
  39. true object oriented architecture with tagged storage, like the old Intel
  40. 432 or the IBM System 38.  But the trend seems to be in the opposite
  41. direction, and operating systems seem to be getting more primitive, yet
  42. bloated, every year.  Multitasking was common on all computers in the mid
  43. 1960s, then pretty much disappeared in the 80s when everyone started running
  44. MS-DOS.  I'm waiting for the days when we all have to start using batch
  45. again.  All this is enough to make an old systems guy like me want to retire
  46. to a small midwestern town and spend his summers in places like Tanjung
  47. Pinang.
  48.  
  49. Anyway, where was I?  Oh yes, mutex locks.  These problems are nearly
  50. impossible to track down.  Since the sfcbs are central to ios, it's very
  51. hard to do anything in the debugger if, for example, you've set a breakpoint
  52. in mutex_$lock.  Everybody and his mother calls mutex_$lock, so you might
  53. have to hit it 10000000 times before catching the one time that has no
  54. matching unlock.  And then, how do you know when that happens?  It's a
  55. Turing completion problem.  How do you tell the debugger to breakpoint on
  56. something that isn't going to happen?  "Please stop the next time
  57. mutex_$unlock *isn't* called."  And if you do manage to catch it, there you
  58. are with the sfcbs locked, and you can't do any IO.  And remember that the
  59. missing unlock can happen in any process.
  60.  
  61. Even worse is the case where it isn't an unmatched lock, it's some random
  62. trashing of memory that happens to scribble on the sfcb.  It can happen at
  63. any time, in any process.
  64.  
  65. Last time I wrote a type manager (for AFS), I had a few of these problems.
  66. I couldn't debug them.  I fixed them by tenacious examination of source
  67. code.  I suspect that's how Apollo engineers fix them too, the few who are
  68. left who even know what an sfcb is.
  69.  
  70. To Apollo's credit, I have to say that I haven't seen a single stuck mutex
  71. since I installed sr10.3.  I suspect there were some problems with TCP
  72. before this but I wouldn't swear to it -- it may have been my screwy type
  73. manager.
  74.  
  75. Enough ranting.
  76.