Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rtech.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!mit-eddie!godot!harvard!seismo!umcp-cs!gymble!lll-crg!dual!unisoft!mtxinu!rtech!jeff From: jeff@rtech.ARPA (Jeff Lichtman) Newsgroups: net.arch Subject: Re: RMS v/s UNIX (non-religious) Message-ID: <217@rtech.ARPA> Date: Fri, 8-Mar-85 15:07:25 EST Article-I.D.: rtech.217 Posted: Fri Mar 8 15:07:25 1985 Date-Received: Mon, 11-Mar-85 06:54:20 EST References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> <2799@dartvax.UUCP> Organization: Relational Technology, Berkeley CA Lines: 27 > > VMS, on the other hand, has a locking mechanism that locks magic cookies; > > ... > > This means you can lock things other than files; perhaps locking should > > have nothing to do with the file system. > > (in my opinion) Locking should have a lot to do with the file system. > ... > The > cooperating applications simply agree on the name of a file. To lock > the magic cookie, a process opens the file with all permissions. To > unlock the magic cookie, the process closes the file. > > Thanks, chuck_simmons%dcts1@dartvax Why should one have to pay the overhead of opening a file in order to obtain a lock? Opening a file is expensive on every operating system I know about. Also, you would be forced to have a file for every (non-file) object you wanted to lock. If you couldn't predict in advance the number of locks your program was likely to get, you would either have to create a enough files in advance to handle the worst case, or you would have to create the files on the fly (more overhead!). I feel that the file system should call the lock manager, and that one should have the option when opening a file to speciify the type of locking to use. Using the file system to do locking requires too much overhead and/or advance allocation of resources. -- Jeff Lichtman at rtech (Relational Technology, Inc.) aka Swazoo Koolak