What Unix needs in file locking

[alan l wendt]

Me:

The second exclusive lock should fail, because that's safer.
The two calls might very well be embedded deep in libraries and
not know about each other.  If you do an flock it's usually because
you intend to read something in and modify it, and if you allow
pairs of locks in the same process you can get duplicated bits of
data.  With two widely separated flock calls for which you may
not even have source code, you can't assume that the conflict
is benign.

Root Boy Jim (mail message):

agreed.

ME:

If you want conflicting locks to succeed within a single process,
on the other hand, it will usually be because you yourself are
writing both flock calls and know that the conflict is benign.
In that case, you can easily implement your preference by interpolating
your own manager in between your calls and the calls on flock.

RBJ:

Which brings up another point. On failure, why not have flock return
the negative of the pid that has the exclusive lock? No flames saying
`systems calls should always return -1 on failure'.

ME:

That's a wonderful idea for two reasons.

First, you can then if you wish ignore conflicts with yourself.

Second and more important, because it allows you to "cache"
locks, and only release them when another process needs them.
The idea is that when the kernel sends you back such a notification,
you send a message to that process and request that it release the
lock.  If it actually needs the lock, it declines.  If it is just
caching the lock, it agrees, releases it to the kernel, and you
then retry the lock request.

Caching locks is not necessarily a big win by itself.  It does
save you some system calls if you are the only one using the file
because you'll simply accumulate the locks in your address space
and refer to them instead of going back to the system all the
time.  But, you cannot cache data without also caching the locks on
the data.  And if the lock manager and the data storage are on another
machine, caching can be a big win.

Kai Li at Princeton has written about systems like this,
although he doesn't call it "lock caching", which seems
like the natural term for it.

Alan W.