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