home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / wizards / 3621 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  3.3 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: flock(2) emulation?
  5. Message-ID: <14071@auspex-gw.auspex.com>
  6. Date: 15 Aug 92 00:06:21 GMT
  7. References: <BsrzAp.7KD@ef2007.efhd.ford.com> <19480@fritz.filenet.com> <1992Aug14.171020.20534@krfiny.uucp>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 71
  11. Nntp-Posting-Host: bootme.auspex.com
  12.  
  13. >If I recall the history correctly:
  14.  
  15. Not completely.
  16.  
  17. >first was lockf(3) - a library that provided advisory record locking.
  18. >Then it was rolled into the OS
  19.  
  20. (Presumably meaning "rolled into the kernel"; the kernel isn't all there
  21. is to the OS....)
  22.  
  23. Actually, the original "lockf()" *was* in the kernel.
  24.  
  25. > as flock(2),
  26.  
  27. "flock()" was a *separate* locking mechanism, which showed up in 4.2BSD
  28. (maybe earlier; I don't know if Berkeley invented it or not).
  29.  
  30. >and lockf(3) became simply calls to flock.
  31.  
  32. It sounds as if you're thinking of System V-style locking with
  33. "fcntl()"; AT&T put that in some SVR2-vintage release, and made
  34. "lockf()" a library routine wrapped around it.
  35.  
  36. >This enabled manditory record locking
  37. >(write(2) returns EAGAIN or blocks if it would overwrite a locked
  38. >region of the file).
  39.  
  40. The "lockf()" implementation by John Bass (which was, I think, the first
  41. one; published in an issue of ";login:", as I remember) had mandatory
  42. record locking - it was, I think, the *only* kind of locking it had. 
  43. Other byte-span locking implementations may have done only advisory
  44. locking, or have done both (the AT&T "fcntl()" locking did both).
  45.  
  46. >As mentioned in this newsgroup, the library probably kept a file
  47. >containing
  48. >- the file being locked (by major number/minor number/inode)
  49. >- the region locked and the PID
  50. >that way, all processes can access the global file and
  51. >inspect each other's locks.
  52.  
  53. Nope.  The original implementation kept such a database, but it kept it
  54. in the kernel, rather than in a file.
  55.  
  56. >The problem with advisory record locking is that a 'rude'
  57. >program that doesn't respect the locking can destroy the file.
  58. >Manditory record locking (having a file with the "get GID bit" set)
  59. >enforces the lock by blocking writes on locked portions.
  60.  
  61. The problem with mandatory record locking is that a "rude" program can
  62. lock a file and never unlock it; for example, it could stick a read lock
  63. on, say, "/etc/passwd" and hang onto it forever.  That's why it's not
  64. the default....
  65.  
  66. Many OSes offer, from what I can tell, only advisory locking;
  67. admittedly, they're OSes not used much for commercial data processing,
  68. such as IBM's MVS and VMS. :-)
  69.  
  70. In other words, the lack of mandatory record locking isn't necessarily
  71. crippling; OS/360 and successors seem to have gotten along without it. 
  72. Of course, in those OSes, those files that require locks are generally
  73. accessed through a library that does the locking for you, so you
  74. probably have to do a lot more work to write such a rude program.
  75.  
  76. Frankly, if there's some UNIX programmer who can't manage to get locking
  77. right, I wouldn't trust them to access such a file *except* through e.g. 
  78. some ISAM package; said package would, presumably, not only manage the
  79. index, etc., better than said programmer's code could, it would also
  80. manage locks better than their code could.
  81.  
  82. As I remember, AT&T's documentation recommends *against* using mandatory
  83. locking....
  84.