wendt@segovia.CS.ColoState.Edu (alan l wendt) (08/08/89)
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.