Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site u1100s.UUCP Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!cord!hudson!bentley!hoxna!houxm!whuxl!whuxlm!spuxll!abnji!u1100a!u1100s!sjs From: sjs@u1100s.UUCP (Stan Switzer) Newsgroups: net.arch Subject: Magic Cookies and File Systems Message-ID: <190@u1100s.UUCP> Date: Mon, 4-Mar-85 09:17:14 EST Article-I.D.: u1100s.190 Posted: Mon Mar 4 09:17:14 1985 Date-Received: Thu, 7-Mar-85 04:06:54 EST References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> Reply-To: sjs@u1100s.UUCP (Stan Switzer) Organization: Bell Communications Research, Piscataway, NJ Lines: 38 Summary: [ does this really belong in net.arch? ] In article <538@rlgvax.UUCP> guy@rlgvax.UUCP (Guy Harris) writes: > > The problem lies in picking an underlying model sufficiently robust > > to do all of the things you want to do with record and file locking, ... > > Well, several UNIX versions *do* have record and file locking - System V > Release 2 Version 2, for one. They are based on John Bass' byte-stream > locking mechanism; you lock a given range of bytes in the file. > > VMS, on the other hand, has a locking mechanism that locks magic cookies; > cooperating applications agree on a name for a resource and they lock > that name when they want to lock that resource. ... > ... > This means you can lock things other than files; perhaps locking should > have nothing to do with the file system. On the contrary, all magic cookies should be tied to the file system in some way. It really burns me the way some message passing, locking, and semaphore systems use a globally administered pool of names (or worse yet, numbers!!) for the names of entities. The file system directory structure is the ONLY logical place for global names of ANY kind to reside. UNIX drew on this idea from MULTICS, and used it to good advantage. As in MULTICS, devices and executable programs are just a particular kind of enrty in the file system. In MULTICS it went further: memory, in fact everything, was named in the file system. Actually I agree about locking resources, but locking ranges of bytes in files is useful too. Anyway, for the purpose of locking resources, you just need a file (special or otherwise) to represent a resource, and you do your locking against that file. IF SOMETHING NEEDS A NAME, PUT IT IN THE FILE SYSTEM!!!!!!!!!!!!!!! -------------------------------------------------------------------------- Stan Switzer | "We're gonna have a TV party tonight. ihnp4!u1100s!sjs | Alright!" -- Black Flag