home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / nfs / 1915 < prev    next >
Encoding:
Text File  |  1992-07-21  |  1.7 KB  |  37 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!sun-barr!ames!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: lockd
  5. Message-ID: <nje1jic@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Jul21.174721.26888@nntpd.lkg.dec.com> <14hpi3INNppo@seven-up.East.Sun.COM>
  8. Date: Wed, 22 Jul 1992 00:20:54 GMT
  9. Lines: 26
  10.  
  11. In article <14hpi3INNppo@seven-up.East.Sun.COM>, geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
  12. > ...
  13. > Why? Because back in 1986 it wasn't practical to create a multithreaded
  14. > lock manager.
  15.  
  16.  
  17. This is the first even remotely official statement I've heard that any
  18. of the various versions of lockd owe much to the simple locking demo
  19. program shown at USENIX or whatever in Feb (I think) 1986.  By
  20. listening to what was said in meetings of B.Lyons' group at the time, I
  21. inferred that it was not intended to be a product.  Are you referring
  22. to the same demo?
  23.  
  24. It was not <<technically>> "impractical to create a multithreaded lock
  25. manager" in 1986.  Perhaps no one had the time or inclination, but it
  26. was certainly technically feasible.  "Multi-processing", "threads",
  27. and so on have not changed much since 1986.  It is true that more
  28. companies are shipping multi-processor UNIX systems today, but that is
  29. not relevant.  You don't need more than one processor for a
  30. multi-threaded program.  You don't need klunky things like System V
  31. shared memory and semaphores, which were around in 1986 and might have
  32. been in SunOS--I don't remember.  Lockd on SunOs of that vintage could
  33. probably have used vfork(), although that would have been somewhat kludgy.
  34.  
  35.  
  36. Vernon Schryver,  vjs@sgi.com
  37.