UFS: The Root of All Evil 271 hackers 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).

272 The File System AT&T, meanwhile, was trying to sell Unix into the corporate market, where record locking was required. It came up with the idea of mandatory record locking. So far, so good—until SVR4, when Sun and AT&T had to merge the two different approaches into a single, bloated kernel. Date: Thu, 17 May 90 22:07:20 PDT From: Michael Tiemann cygint!tiemann@labrea.stanford.edu To: UNIX-HATERS Subject: New Unix brain damage discovered I’m sitting next to yet another victim of Unix. We have been friends for years, and many are the flames we have shared about The World’s Worst Operating System (Unix, for you Unix weenies). One of his favorite hating points was the [alleged] lack of file locking. He was always going on about how under real operating systems (ITS and MULTICS among others), one never had to worry about losing mail, losing files, needing to run fsck on every reboot… the minor inconveniences Unix weenies suffer with the zeal of monks engaging in mutual flagellation. For reasons I’d rather not mention, he is trying to fix some code that runs under Unix (who would notice?). Years of nitrous and the Grateful Dead seemed to have little effect on his mind compared with the shock of finding that Unix does not lack locks. Instead of having no locking mechanism, IT HAS TWO!! Of course, both are so unrelated that they know nothing of the other’s existence. But the piece de resistance is that a THIRD system call is needed to tell which of the two locking mechanisms (or both!) are in effect. Michael This doesn’t mean, of course, that you won’t find lock files on your Unix system today. Dependence on lock files is built into many modern Unix utilities, such as the current implementation of UUCP and cu. Furthermore, lock files have such a strong history with Unix that many programmers today are using them, unaware of their problems.