Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site luke.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!bene!luke!bob
From: bob@luke.UUCP (Bob Speray)
Newsgroups: net.database,net.unix
Subject: Re: John Bass locking?
Message-ID: <342@luke.UUCP>
Date: Sat, 12-Oct-85 01:30:08 EDT
Article-I.D.: luke.342
Posted: Sat Oct 12 01:30:08 1985
Date-Received: Mon, 14-Oct-85 03:26:04 EDT
References: <340@luke.UUCP> <245@3comvax.UUCP>
Reply-To: bob@luke.UUCP (Robert Speray)
Organization: Benetics Corp, Mt.View, CA
Lines: 64
Xref: watmath net.database:105 net.unix:5882
Summary: 

In article <245@3comvax.UUCP> mikes@3comvax.UUCP (Mike Shannon) writes:
>	What's the nitty gritty on 'John Bass' locking?  How about some
>history, tradeoffs, etc?

I'm not the best one to talk about this issue.  John Bass, are you out there?

The locking I refer to when using the term "John Bass locking" is a chapter 2 
call provided by the Plexus version of sys3 Unix. I beleive the name
comes from the person who originally championed the cause at Fortune Systems.

Plexus people claim that this same function is defined for unix sys5.2 rel 3
from AT&T.  Plexus unix sys5 version 1.2 has the "locking" call in it.

SYNOPSIS
	locking( fildes, mode, size )  long size;

DESCRIPTION
    Locking allows a specified number of bytes to be accessed only
	by the locking process.  Other proceses that attempt to lock, read,
	or write the locked area must sleep until the area becomes locked.

	Mode is 0 to unlock the area.  Mode is 1 to lock the area with a
	sleep until it is available.  Mode is 2 to lock the area with
	an error return if the area is already locked.

	Deadlock is checked and an error is returned if sleeping on the locked
	error would cause a deadlock.

	Closing fildes automatically releases any locks the process has on
	a file.  (i.e. locks are released at process termination)


In usage, the locking call is preceeded by a file open and an lseek to the
byte offset that is to be locked.  The designated number of bytes from
the current offset are locked.

An entire record image can be reserved for exclusive access, preventing
anyone from even reading it.

The locked bytes do not actually need to exist.  For example,
an empty file can be used as the basis for a protocol between competing 
writing processes.  

Each writing process locks corresponding pseudo "field images" in the 
empty file in order to coordinate updates.  The actual images in the real 
database remain unlocked so that reading processes are not hindered.
Of course, this protocol is not a very good solution for the concurrency 
problem, but it does demonstrate the point of locking non existing bytes.

I think the locking call is a great gain over standard sys3.  Plexus
has done right by providing it.  We use it for more than just "locking".

It has been the best way for us to get semaphores in sys3.
The other technique of opening a file create exclusive as is done by
lpr is just too expensive - several seconds for the open and a file
descriptor consumed for each semaphore.

Having a process's locks cleared by the system on process termination is a real
advantage.  Other models of locking that are implemented at the user level 
have special considerations on error exits, on boots, etc.  That type
activity belongs in the OS.

Robert Speray
Benetics Corp