home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sgi / 18108 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.8 KB  |  67 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!pipex!doc.ic.ac.uk!cc.ic.ac.uk!imperial.ac.uk!vulture
  3. From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
  4. Subject: Re: what is the difference between shared and exclusive file locks?
  5. Message-ID: <1992Dec16.190307.1894@cc.ic.ac.uk>
  6. Sender: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
  7. Nntp-Posting-Host: cscgc
  8. Reply-To: cmaae47@imperial.ac.uk
  9. Organization: Imperial College of Science, Technology and Medicine
  10. References: <1992Dec15.131211.10307@wl.com>
  11. Distribution: usa
  12. Date: Wed, 16 Dec 92 19:03:06 GMT
  13. Lines: 52
  14.  
  15. In article <1992Dec15.131211.10307@wl.com>, agrafiot@wl.com (Dimitris Agrafiotis) writes:
  16.  
  17. - Can somebody explain to me what the difference between shared and 
  18. - exclusive locks is (LOCK_SH/LOCK_EX in flock()).
  19.  
  20. Shared file locks prevent other processes from writing the file, but they
  21. can still read it.
  22.  
  23. Exclusive locks should prevent other processes from reading the file, as
  24. the locking process is about to change it.
  25.  
  26. Thus when you want to modify a file, you should 
  27.  
  28.     o  obtain a shared lock
  29.     o  read some information
  30.     o  release the lock
  31.     o  modify the information as desired
  32.  
  33.     o  obtain an exclusive lock
  34.     o  re-read the information
  35.     o  compare it with the previously read one
  36.     o  if the compare fails but the differences can be consolidated, do so
  37.     o  if the differences can not be consolidated abort the update
  38.     o  if the compare is ok write the information back
  39.     o  release the lock
  40.  
  41. The first lock ensures nobody else actually modifies what you read while
  42. you read it, the second lock stops other people reading information which
  43. will soon be out of date.
  44.  
  45. The two stage process is necessary when the modification takes a significant
  46. time, for example when fields are updated in terminal interactions. It could
  47. be that the user is shot without finding time to close the transaction 
  48. properly, leaving you with a database you can no longer modify until you 
  49. clear the lock manually or reboot the system.
  50.  
  51. In client server environments there is often a specific server process that 
  52. locks the file exclusively. All other users have to talk to the server to 
  53. get read or modify access to the data, and the server serialises all the transactions.
  54.  
  55. This way a definciency of the unix system (only file locks, no record 
  56. locks) has been turned into a must-have asset - support for client-server
  57. environments and all that.
  58.  
  59.                                         Thomas
  60.  
  61. -- 
  62. *** This is the operative statement, all previous statements are inoperative.
  63. *   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
  64. *   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
  65. *   snail: Imperial College of Science, Technology and Medicine
  66. *   The Center for Computing Services, Kensington SW7 2BX, Great Britain
  67.