Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!ulysses!sfmag!sfsup!dcm
From: dcm@sfsup.UUCP (David C. Miller, consultant)
Newsgroups: comp.unix.wizards
Subject: Re: lockf and the SVID, (Was "Re: Wanted: lockf system call source")
Message-ID: <881@sfsup.UUCP>
Date: Wed, 3-Dec-86 11:21:12 EST
Article-I.D.: sfsup.881
Posted: Wed Dec  3 11:21:12 1986
Date-Received: Thu, 4-Dec-86 02:24:56 EST
References: <5413@brl-smoke.ARPA> <2264@sdcsvax.UCSD.EDU> <1062@ihdev.UUCP>
Reply-To: dcm@sfsup.UUCP (David C. Miller, consultant)
Organization: AT&T Information Systems, Summit N.J.
Lines: 32

In article <1062@ihdev.UUCP> pdg@ihdev.UUCP (55224-P. D. Guthrie) writes:
>[ Oh line eater, line eater, wherefor art thou? ]
>
>In article <2264@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes:
>>[...]
>>I can see a reasonable scenario where a program reading a file might not
>>want the record it is looking at changed under it.  This would seem pretty
>>common when dealing with multiple processes accessing a database.  What
>>gives?
>
>Well, in a situation like this, you would most likely have the process
>doing the writing provide advisory read locking.  The situation you
>describe would seem to suggest cooperating programs to some extent
>(multiple processes accessing a database).  In this case you simply have
>the writing process turn on write and read locks before writing.  In
>this way your read process would fail, not the write process (more
>important in most applications), and have to re-read - getting the new
>data.  This does the same thing in a slightly more elegent manner.
>
>[...]
>
>Paul Guthrie					We come in peace,
>ihnp4!ihdev!pdg					We bring BEER!

If we're talking "cooperatve" processes, then there is really no problem.
According the the SVR3 manual, a read locked area/file cannot be write locked
and a write locked area/file cannot be read locked (or write locked by a second
process).  Therefore, all that is necessary is for the writing process to
require a write lock before proceding.  If another process has a read lock,
then the write lock will fail and the writing process will have to wait.
Granted, in most applications, the writing process should have priority,
but this way both processes have about the same.