sasaki@harvard.ARPA (Marty Sasaki) (09/09/85)
This got beaten to death a while ago in net.arch, but let me add my
two cents. I believe that the issue of database locking is too
complicated to be done in the operating system. The best thing to do
would be to provide a simple, easy to use, efficient, lock mechanism
in the operating system. A database daemon, or a magic device driver
could then implement the desired scheme for the database using the
primitives provided by the system.
VMS (no flames please) has such a lock manager. The idea is that locks
are named when they are created. There are primities to lock, unlock,
and wait on locks. All that is required is that users agree on a
naming scheme for the locks.
--
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138jerry@uwmcsd1.UUCP (Jerry Lieberthal) (09/10/85)
> This got beaten to death a while ago in net.arch, but let me add my > two cents. I believe that the issue of database locking is too > complicated to be done in the operating system. The best thing to do > would be to provide a simple, easy to use, efficient, lock mechanism > VMS (no flames please) has such a lock manager. The idea is that locks > are named when they are created. There are primities to lock, unlock, > and wait on locks. All that is required is that users agree on a > One Oxford Street > Cambridge, MA 02138 This is also true of the Sperry implementation (DMS 1100) which is a network arch. database with locks around the world (maybe that's why users spend so much of their time locking/unlocking that the update never gets done :-)). The locks are implemented in the equivalent of a daemon and not really in the OS (although Sperry has hooks there too if you want to use them). -- ------------------------------------------------ - jerry University of Wisconsin-Milwaukee Computing Services Division ihnp4!uwmcsd1!jerry uwmcsd1!jerry@wisc-rsch.ARPA "HALT, or you will exterminateeedddd......" <sounds of meltdown follow> | | |-------> sound of generic DALEK fadeout ...
david@ukma.UUCP (David Herron, NPR Lover) (09/13/85)
In article <341@harvard.ARPA> sasaki@harvard.UUCP (Marty sasaki) writes: >VMS (no flames please) has such a lock manager. The idea is that locks >are named when they are created. There are primities to lock, unlock, >and wait on locks. All that is required is that users agree on a >naming scheme for the locks. Seems to me that Unix already has something that comes very very close to this. Here's the method. Create a Well-Known-Directory (say, /locks) that's mode 777. To make a lock (you need a Well-Known-Name for the lock) you creat() it, and specify exclusive open at the same time. You keep the fd to the lock file open for as long as you're wanting the lock kept open. Then you unlink() it. Only problem is waiting on the lock. (well, you could do a work around with alarm() and a signal() handler). Does System V and friends have exclusive opens? -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david Hackin's in me blood. My mother was known as Miss Hacker before she married!
dhp@ihnp3.UUCP (Douglas H. Price) (09/13/85)
Unfortunately, creating a file is about the second most expensive thing you can do in UN*X (the first being fork/exec). The problem is not one of capability, but of efficiency. So, if you ignore the possibility of a driver-mediated form of locking, I end up agreeing with the concept of a Operating System supported set of locks, preferably addressed with some form of namespace. Note that System V+ machines have this capability in the form of the semaphore ops, though I might argue with the naming and scoping rules currently implemented. -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihnp3!dhp
henry@utzoo.UUCP (Henry Spencer) (09/13/85)
> The best thing to do > would be to provide a simple, easy to use, efficient, lock mechanism > in the operating system... [for use in implementing the desired scheme] No argument. > VMS (no flames please) has such a lock manager. Unix has a file system, which can be used for the same thing. > The idea is that locks are named when they are created. Files are named when they are created. > There are primities to lock, unlock, and wait on locks. There are primitives to link and unlink files. There is no easy way to wait, which is a serious blemish. > All that is required is that users agree on a > naming scheme for the locks. I.e., for the files. Simple? Yes, except for the wait problem. Easy to use? Yes, except for the wait problem. Efficient? Not outstandingly, but *this* can be addressed without inventing any new semantics (except for the w.p.); it's easy enough to create a driver for a little filesystem that lives in main memory, eliminating disk overhead. Even the wait problem can be licked if you have named pipes (aka fifos): read-one-byte and write- one-byte become lock+wait and unlock, although you need the clumsy and ugly non-blocking read to get a non-blocking-lock-attempt operation. In short, don't re-invent the wheel if the one you've got is already almost round enough. Round off the existing one instead. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/14/85)
> Does System V and friends have exclusive opens?
On O_CREAT, yes. SVR2.2 and later also have read/write file/record
cooperative locking.carter@masscomp.UUCP (Jeff Carter) (09/14/85)
In article <2170@ukma.UUCP> david@ukma.UUCP (David Herron, NPR Lover) writes: >In article <341@harvard.ARPA> sasaki@harvard.UUCP (Marty sasaki) writes: >>VMS (no flames please) has such a lock manager. The idea is that locks >>are named when they are created. There are primities to lock, unlock, >>and wait on locks. All that is required is that users agree on a > >Seems to me that Unix already has something that comes very very close >to this. >Does System V and friends have exclusive opens? Well, yes, but why bother? The desired quality is a resource lock, not yet-another-UNIX-hack-to-get-around-missing-facility. System V r2 has a series of mechanisms used for inter-process communication, known collectively as 'Sys V IPC'. The three items are: dynamic shared memory, message queues, and semaphores. A semaphore sounds like just the thing you need: It is maintained in the kernel (read: fast for IPC, and inviolate by user code). The multiple processes using the semaphore can query its current value, atomically increment or decrement the value, or block waiting for a given value. A mechanism is also built in so that if a process exits or is killed unexpectedly, the semaphore is changed to be 'untouched' (this is selectable), so that the arbitrated-for resource will not become unavailable. Utilities are provided that can query and change the IPC structures, so if something goes wrong, you can fix it. Also, semaphores are a data structure, so they go away after a reboot or crash. Ever have a machine crash while something that uses lock files (like uucp) is running? Finding lock files and blowing them away is unacceptable. Jeff Carter MASSCOMP 1 Technology Park Westford, MA 01886 ...!{ihnp4|decvax|harvard}!masscomp!carter
johnl@ima.UUCP (09/14/85)
/* 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
hokey@plus5.UUCP (Hokey) (09/16/85)
The semaphores provided in SysV don't implement a queue, though. A test program was posted a while ago which shows that the semaphores implement a *stack*! Just think of the possibilities... The first in line is the last in line! Somebody (I forget who) at AT&T pointed out that all that was needed to fix this was to change the code which puts processes awaiting semaphores to sleep. I do not know if this has been fixed, yet. Since we have only recently begun seeing net.database in a consistent fashion, I don't know if the issues surrounding file vs. record locks has been fully beaten up. There are definitely needs for both, depending on the application. I am told that implementing record locks in a distributed environment is Nasty (Hi Clem!). I am almost sorry I missed all the discussion on promotable locks. -- Hokey ..ihnp4!plus5!hokey 314-725-9492