UFS: The Root of All Evil 271hackers finally realized that lock files had to be made and maintained, they
came up with the “lock file.”
You need an “atomic operation” to build a locking system. These are oper-
ations that cannot be interrupted midstream. Programs under Unix are like
siblings fighting over a toy. In this case, the toy is called the “CPU,” and it
is constantly being fought over. The trick is to not give up the CPU at
embarrassing moments. An atomic operation is guaranteed to complete
without your stupid kid brother grabbing the CPU out from under you.
Unix has a jury-rigged solution called the lock file, whose basic premise is
that creating a file is an atomic operation; a file can’t be created when one
is already there. When a program wants to make a change to a critical
database called losers, the program would first create a lock file called
losers.lck. If the program succeed in creating the file, it would assume that
it had the lock and could go and play with the losers file. When it was
done, it would delete the file losers.lck. Other programs seeking to modify
the losers file at the same time would not be able to create the file
losers.lck. Instead, they would execute a sleep call—and wait for a few
seconds—and try again.
This “solution” had an immediate drawback: processes wasted CPU time
by attempting over and over again to create locks. A more severe problem
occurred when the system (or the program creating the lock file) crashed
because the lock file would outlive the process that created it and the file
would remain forever locked. The solution that was hacked up stored the
process ID of the lock-making process inside the lock file, similar to an air-
line passenger putting name tags on her luggage. When a program finds the
lock file, it searches the process table for the process that created the lock
file, similar to an airline attempting to find the luggage’s owner by driving
up and down the streets of the disembarkation point. If the process isn’t
found, it means that the process died, and the lock file is deleted. The pro-
gram then tries again to obtain the lock. Another kludge, another reason
Unix runs so slowly.
After a while of losing with this approach, Berkeley came up with the con-
cept of advisory locks. To quote from the flock(2) man page (we’re not
making this up):
Advisory locks allow cooperating processes to perform consistent
operations on files, but do not guarantee consistency (i.e., processes
may still access files without using advisory locks possibly resulting
in inconsistencies).