Determining if an existant file is open

[Dan Bernstein]

Here's a way to simulate safe locks without flock() or lockf().

1. Create wantlock.time.pid, filling in the current time and pid in
whatever format. Put enough information in it that a later process can
detect if you crash. (If the only reason for such a crash is system
failure, and if each system failure is logged in a central file, it's
enough to leave wantlock empty and depend on the timestamps. Otherwise
you should create the file as temp.time.pid, then write the necessary
information, then move it to wantlock.time.pid.)

2. Read the directory. If the first wantlock (in order of time, and then
in order of pid) is yours, go ahead and use the resource. Otherwise
sleep a second and repeat this step. Make sure to remove (ignoring
ENOENT) any file (before yours in time order) whose process has crashed.
This step requires a semblance of intelligence in your directory-reading
mechanism---no matter what other operations are going on, the system
must guarantee that you see every existing file that was created before
you opened the directory, and that you won't keep reading filenames
forever if some other process keeps creating files.

3. When you are finished with the resource, remove the wantlock file.

One strategy for implementing #1 is to create wantlock as a named pipe.
Then #2 opens the pipe in nonblocking mode to see if the process is
still alive.

An alternative way to detect crashes is to clear the locks on each
reboot, but unless the resource is centralized this can be a pain.

In article <1990Nov25.014317.11660 at nusdecs.uucp> rwhite at nusdecs.uucp (0257014-Robert White(140)) writes:
> In article <26251:Nov2119:42:1090 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >In article <274975C4.21C at tct.uucp> chip at tct.uucp (Chip Salzenberg) writes:
> >> According to rwhite at nusdecs.uucp (0257014-Robert White(140)):
> >> >Do the "put process number in lock file" thing as in uucp.
> >> For you doubters: Once you've determined that a lock file is stale and
> >> you want to unlink() it, how do you know the lock file hasn't been
> >> replaced in between the decision to unlink() and the unlink() itself?
> >The old name will never be reused, so there's no danger of replacement.
> The above is (except for my comment) incorrect.

Uh, you left out what I said before that ``incorrect'' statement: viz.,
if you include appropriate information in the name of the lock file,
Chip's objections disappear. In the situation he describes, the old name
will never be reused, so there's no danger of replacement.

In other words, you take advantage of the kernel's synchronization
mechanisms for directories. This is often easier than using higher-level
lock mechanisms. (The three-step method above is pretty simple.)

> The application of the
> basic rules of computer science reveals the following procedure:
> Given:  A singular lock file name (multiple names is a waste of effort).

What are ``the basic rules of computer science''? Using multiple names
solves the problem, so obviously it isn't a waste of effort. Not that
there's anything wrong with the method you outline, but kernel locks are
not necessary to implement higher-level locks.

> Lock the file for exclusive Access.
> 	<Once you own the lock on the file there is no chance of>
> 	<confilict durring lock validation.  The requestors will>
> 	<be FIFO(ed) by the locking mechanisim.

Actually, there's no guarantee that the other processes are handled FIFO
by the kernel lock (at least on some UNIX systems). The method I outline
does guarantee FIFO behavior.

---Dan