ptg10805159Section 14.3 RecordLocking 499
This program creates a file and enables mandatory locking for the file. The program
then splits into parent and child, with the parent obtaining a write lock on the entirefile.
The child first sets its descriptor to be nonblocking and then attempts to obtain a read
lock on the file, expecting to get an error.This lets us see whether the system returns
EACCESorEAGAIN.Next, the child rewinds the file and tries toreadfrom the file. If
mandatory locking is provided, thereadshould returnEACCESorEAGAIN(since the
descriptor is nonblocking). Otherwise, thereadreturns the data that it read. Running
this program under Solaris 10 (which supports mandatory locking) gives us
$./a.out temp.lock
read_lock of already-locked region returns 11
read failed (mandatory locking works): Resource temporarily unavailable
If we look at either the system’s headers or theintro(2) manual page, we see that an
errnoof 11corresponds toEAGAIN.Under FreeBSD 8.0, we get
$./a.out temp.lock
read_lock of already-locked region returns 35
read OK (no mandatory locking), buf = ab
Here, anerrnoof 35 corresponds toEAGAIN.Mandatory locking is not supported.Example
Let’s return to the first question posed in this section: what happens when two people
edit the same file at the same time? The normal UNIX System text editors do not use
recordlocking, so the answer is still that the final result of the file corresponds to the last
process that wrote the file.
Some versions of thevieditor use advisory recordlocking. Even if we wereusing
one of these versions ofvi,itstill doesn’t prevent users from running another editor
that doesn’t use advisory recordlocking.
If the system provides mandatory recordlocking, we could modify our favorite
editor to use it (if we have the editor’s source code). Not having the source code for the
editor, we might try the following.We write our own program that is a front end tovi.
This program immediately callsfork,and the parent just waits for the child to
complete. The child opens the file specified on the command line, enables mandatory
locking, obtains a write lock on the entirefile, and then executesvi.While viis
running, the file is write locked, so other users can’t modify it. Whenviterminates, the
parent’swaitreturns and our front end terminates.
Asmall front-end program of this type can be written, but it doesn’t work. The
problem is that it is common practice for editors to read their input file and then close it.
Alock is released on a file whenever a descriptor that references that file is closed. As a
result, when the editor closes the file after reading its contents, the lock is gone. Thereis
no way to prevent this from happening in the front-end program.We’ll use recordlocking in Chapter 20 in our database library to provide concurrent
access to multiple processes. We’ll also provide some timing measurements to see how
recordlocking affects a process.