bin@primate.wisc.edu (Brain in Neutral) (07/25/89)
Should a single process be able to acquire an exclusive lock on a file twice? It would seem to me "no", given the usual meaning of "exclusive". However, differing systems give me differing results for the following program. # include <sys/file.h> # include <errno.h> main () { extern int errno; int f1, f2; f1 = open ("junk", O_WRONLY|O_CREAT, 0644); if (f1 < 0) { perror ("f1 open"); exit (1); } printf ("f1 opened\n"); if (flock (f1, LOCK_EX|LOCK_NB) < 0) { if (errno == EWOULDBLOCK) { perror ("f1 flock1"); exit (1); } perror ("f1 flock2"); exit(1); } printf ("f1 locked\n"); f2 = open ("junk", O_WRONLY|O_CREAT, 0644); if (f2 < 0) { perror ("f2 open"); exit (1); } printf ("f2 opened\n"); if (flock (f2, LOCK_EX|LOCK_NB) < 0) { if (errno == EWOULDBLOCK) { perror ("f2 flock1"); exit (1); } perror ("f2 flock2"); exit(1); } printf ("f2 locked\n"); } On a VAX (Ultrix 2.2 or 1.2) I get the following output, as expected: f1 opened f1 locked f2 opened f2 flock1: Operation would block On a MIPS M/120 (RISC/os 4.0) I get, unexpectedly: f1 opened f1 locked f2 opened f2 locked In other words, the process acquires two exclusive locks. Am I correct in thinking this is a bug in flock? Paul DuBois dubois@primate.wisc.edu
rogerk@mips.COM (Roger B.A. Klorese) (07/25/89)
In article <136@uakari.primate.wisc.edu> bin@primate.wisc.edu (Brain in Neutral) writes: >Should a single process be able to acquire an exclusive lock on a file >twice? It would seem to me "no", given the usual meaning of "exclusive". I tend to agree. It's bug #4810. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary
rogerk@mips.COM (Roger B.A. Klorese) (07/26/89)
In article <23988@abbott.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >In article <136@uakari.primate.wisc.edu> bin@primate.wisc.edu (Brain in Neutral) writes: >>Should a single process be able to acquire an exclusive lock on a file >>twice? It would seem to me "no", given the usual meaning of "exclusive". > >I tend to agree. It's bug #4810. ...and a fix has already been checked in, which will appear in release 4.02 (if there is one) or 5.00. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/27/89)
In article <136@uakari.primate.wisc.edu> bin@primate.wisc.edu (Brain in Neutral) writes: >In other words, the process acquires two exclusive locks. Am I correct >in thinking this is a bug in flock? The Ultrix v3 man page tells me that flock() is for cooperating processes. Processes should be able to cooperate with themselves ... On Ultrix v3 the second flock fails returning EWOULDBLOCK I `feel' that the second lock should succeed ... but haven't read any of the Official Standards Work so don't know the basis. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- "Amiga software is as good and as bad as PC software. The difference is <- that AmigaDOS waves bye-bye before it dies, while the PC just freezes."
wendt@segovia.CS.ColoState.Edu (alan l wendt) (07/28/89)
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. 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. Alan Wendt