Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ima.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!yale!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.database
Subject: Re: locks
Message-ID: <121200006@ima.UUCP>
Date: Sat, 14-Sep-85 16:03:00 EDT
Article-I.D.: ima.121200006
Posted: Sat Sep 14 16:03:00 1985
Date-Received: Mon, 16-Sep-85 00:04:28 EDT
References: <341@harvard.UUCP>
Lines: 20
Nf-ID: #R:harvard:-34100:ima:121200006:000:1044
Nf-From: ima!johnl    Sep 14 16:03:00 1985


/* Written 11:27 pm  Sep 12, 1985 by david@ukma in ima:net.database */
> Seems to me that Unix already has something that comes very very close
> to this.  [... describes traditional hack of linking to a well-known
> file name or opening it exclusively ]

It's true, that technique works, but there are several reasons that it's
not enough for serious data base work.  The first is that it's just too
slow.  It would typically require 3 or 4 disk accesses, and that's often
more I/O that the whole transaction it's supposed to protect.  The second
is that there's no way to wait for a lock other than sleeping and polling,
which is also too slow.  The third is that detecting stale locks (from
before a reboot, or from a process that accidentally died) is also slow.

The /usr/group locking scheme proposed by John Bass is certainly a step
in the right direction, since it needs no I/O to lock or unlock a lock,
has a way to directly wait for a lock to be available, and automatically
unlocks locks when a process dies.

John Levine, ima!johnl


Brought to you by Super Global Mega Corp .com