Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watdcsu.UUCP Path: utzoo!watmath!watdcsu!herbie From: herbie@watdcsu.UUCP (Herb Chong [DCS]) Newsgroups: net.arch Subject: Re: Magic Cookies and File Systems (Religious FLAME) Message-ID: <1078@watdcsu.UUCP> Date: Wed, 6-Mar-85 20:27:29 EST Article-I.D.: watdcsu.1078 Posted: Wed Mar 6 20:27:29 1985 Date-Received: Thu, 7-Mar-85 04:08:54 EST References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> <190@u1100s.UUCP> Reply-To: herbie@watdcsu.UUCP (Herb Chong [DCS]) Organization: U of Waterloo Lines: 95 Summary: In article <190@u1100s.UUCP> sjs@u1100s.UUCP (Stan Switzer) writes: >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. and you pay for it too unless your entire file directory resides in memory all the time, in which case you have consistency problems, not to mention taking up real memory which could be allocated to other things besides file names. numbers are perfectly reasonable things to have as names of entities. are you going to read and make decisions based upon these names? no, a program is going to, and it is just as happy with a short name(word) as a long one, but a long one takes up so much more space. >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. and look at how much overhead MULTICS has. not that MULTICS is bad conceptually, but why run a system that permanently takes away more than half your CPU for overhead when you can run Unix, which is just about as flexible most of the time, and you get one quarter or more of your CPU back to boot. >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. locking bytes, or inability to do so, is as much a function of hardware as software. implementation that is both efficient in memory and time requires some help from both. >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 there is something very fundamentally wrong here with stan's argument. how do i ensure no two people have locked on the same file at the same time? no, you can't do an i/o to find out, because the other process may be queued just ahead of you for the device so that a query finds it unlocked, but the locking command (i/o or whatever) encounters an already locked file. but this is a dumb disk, it just goes ahead and locks it anyway. so now you have two processes with exclusive access to the lock at the same time. you can imagine what will happen when both try to write to the file. you have to check before you actually lock in a manner that will guarantee exclusive access by one process so what do you do? you lock on a bit (word or whatever) in memory and THEN lock on the file. but why bother locking on the file when you couldn't care less about the file but some other shared resource. AH, but a SMART disk drive would stop this. big deal, the lock is still in memory, but it's the device controller's now. still not on disk. now, let's give the bit a NAME, so it's not fixed to any one location in storage. need i go on? for those of you who don't know, OS/360 (really MVS) has both internal named locks (ENQ/DEQ) and file locks. in a multiple processor environment without shared memory, file locks are used because there is really no other way. the controller has the smarts to acknowledge a RESERVE and prevent all I/O from any other CPU's to that device until the CPU issuing the RESERVE is finished with it. (i might mention at this point that a small MVS system will only have 30 or 40 disk devices attached.) when the processors share memory, the memory management units serialize access to shared storage so that a locking technique works with words (actually, double words) for all shared resources. speed is of main concern here. you do not want to tie up a shared resource more than you have to when a typical i/o instruction can take tens of thousands of CPU cycles and you need to do at least two to lock on a file by setting bits in the filesystem. why two? one to issue the lock, and another to see if you really got it. if you don't have to do the last one, then you're already got "magic cookies" that don't use the file system. there is a very pragmatic reason for using using named "magic cookies" in a system for interprocess synchronization rather than the file system. it takes orders of magitudes less time and the system can continue to schedule processes instead of waiting around for a lock to be satisfied. also, since the lock is in memory and never needs to be updated to disk, consistency of the locks is ensured with much less overhead. this really belongs in net.flame or net.religion.operating-systems, but i am putting it here since no-one else will pay attention otherwise. Herb Chong... I'm user-friendly -- I don't byte, I nybble.... (but i'm sick and tired of ignorance) UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu