lockf and the SVID, (Was "Re: Wanted: lockf system call source")

[David C. Miller, consultant]

In article <1062 at ihdev.UUCP> pdg at ihdev.UUCP (55224-P. D. Guthrie) writes:
>[ Oh line eater, line eater, wherefor art thou? ]
>
>In article <2264 at sdcsvax.UCSD.EDU> hutch at 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.