chip@ateng.ateng.com (Chip Salzenberg) (11/27/88)
[Followups directed to comp.unix.xenix; you'll see why.] According to guy@auspex.UUCP (Guy Harris): >"Mandatory locking" merely means that if you use >"fcntl" or "lockf" to lock a region of the file, attempts to write the >locked region of the file will block until the lock is released, and >if the lock is also supposed to block attempts to read that region, it >will do that as well. ...and unfortunately, despite all protestations to the contrary, SCO Xenix does *not* comply with the SVID on this topic. Even though it's called "Xenix System V." Under SCO Xenix, there are three locking methods: locking(), a Xenix invention lockf(), per /usr/group and in the SVID fcntl(), in the SVID None, that's right, *none* of these locking methods provides advisory locking under SCO Xenix. Even though fcntl() and lockf() MUST be advisory to conform to the SVID. Instead, we get mandatory locking and, therefore, deadlocks on programs written to the SVID. (I wonder what the merged product does?) A side effect of this is that all files to be locked -- for reading or writing, it doesn't matter -- must be opened with write permissions. Sigh. I tested it on SCO Xenix/286 2.2.1. It's true. I wish it weren't. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
jbayer@ispi.UUCP (Jonathan Bayer) (11/28/88)
In article <1988Nov26.220052.19423@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes:
. [Followups directed to comp.unix.xenix; you'll see why.]
.
. According to guy@auspex.UUCP (Guy Harris):
. >"Mandatory locking" merely means that if you use
. >"fcntl" or "lockf" to lock a region of the file, attempts to write the
. >locked region of the file will block until the lock is released, and
. >if the lock is also supposed to block attempts to read that region, it
. >will do that as well.
.
. ...and unfortunately, despite all protestations to the contrary, SCO Xenix
r does *not* comply with the SVID on this topic. Even though it's called
. "Xenix System V."
.
. Under SCO Xenix, there are three locking methods:
.
. locking(), a Xenix invention
. lockf(), per /usr/group and in the SVID
. fcntl(), in the SVID
.
. None, that's right, *none* of these locking methods provides advisory
. locking under SCO Xenix. Even though fcntl() and lockf() MUST be
. advisory to conform to the SVID. Instead, we get mandatory locking and,
. therefore, deadlocks on programs written to the SVID. (I wonder what
. the merged product does?)
.
. A side effect of this is that all files to be locked -- for reading or
. writing, it doesn't matter -- must be opened with write permissions.
Xenix 2.3 has advisary locking. Also, the release notes for 2.3
go into more detail as to where Xenix fails to meet SVID specs.
Jonathan Bayer
Intelligent Software Products, Inc.erik@mpx2.UUCP (Erik Murrey) (11/28/88)
In article <1988Nov26.220052.19423@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: > >...and unfortunately, despite all protestations to the contrary, SCO Xenix >does *not* comply with the SVID on this topic. Even though it's called >"Xenix System V." This appears to be fixed in 2.3.1. The release notes state that you can select either advisory or mandatory in the x.out header. I haven't tested this, so don't flame me if it doesn't work... ... Erik-- Erik Murrey /| // /~~~~/ | / MPX Data Systems, Inc. / | / / /____/ |/ erik@mpx2.UUCP / / / / /| Data Systems, Inc. {spl1,vu-vlsi,bpa}!mpx1!erik / / / / |====================
how@milhow1.UUCP (Mike Howard) (11/28/88)
In article <1988Nov26.220052.19423@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >[Followups directed to comp.unix.xenix; you'll see why.] > >According to guy@auspex.UUCP (Guy Harris): >>"Mandatory locking" merely means that if you use >>"fcntl" or "lockf" to lock a region of the file, attempts to write the > .... >None, that's right, *none* of these locking methods provides advisory >locking under SCO Xenix. Even though fcntl() and lockf() MUST be >advisory to conform to the SVID. Instead, we get mandatory locking and, Would someone knowledgable please explain (with examples) the distinction between `manditory' and `advisory' locking. (more than 25 words is ok with me :-). -- Mike Howard uunet!milhow1!how
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (11/29/88)
In article <1988Nov26.220052.19423@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: > >...and unfortunately, despite all protestations to the contrary, SCO Xenix >does *not* comply with the SVID on this topic. Even though it's called >"Xenix System V." > >Under SCO Xenix, there are three locking methods: > > locking(), a Xenix invention > lockf(), per /usr/group and in the SVID > fcntl(), in the SVID > >None, that's right, *none* of these locking methods provides advisory >locking under SCO Xenix. Even though fcntl() and lockf() MUST be >advisory to conform to the SVID. Instead, we get mandatory locking and, >therefore, deadlocks on programs written to the SVID. Actually, if you read the fine print in the SVID, you may discover that they are conforming, and that even if they aren't, your claim about conforming programs is not quite on target. In SVR2, advisory locking was introduced via lockf(2) and fcntl(2). A reading of the fine print will turn up a note indicating that this will be changed to be mandatory locking at some unspecified point in the future. In SVR3, the locking became mandatory. If SCO Xenix is SVR2-based, then it would appear that they are not SVID conforming in this regard. If they are SVR3-based then they are conforming. I don't know enough about the product to know one way or the other. One might even argue that by implementing the warning ahead of schedule they are still SVID conforming, even under SVR2. However, a program written to conform to the SVID will have no problems in either case, because the warning in the SVID commentary indicates that your program should make pessimistic assumptions about deadlock. Jonathan S. Shapiro AT&T Bell Laboratories
les@chinet.chi.il.us (Leslie Mikesell) (11/29/88)
In article <228@milhow1.UUCP> how@.UUCP (PUT YOUR NAME HERE) writes: > >Would someone knowledgable please explain (with examples) the distinction >between `manditory' and `advisory' locking. (more than 25 words is ok with >me :-). Dunno if I'm qualified to answer this, but the difference is that advisory locking requires other programs to test for locks using the lockf() or fcntl() (or locking()...) functions. Manditory locks affect all programs whether they check or not. Examples would be a database type program that uses lockf(fd,F_LOCK,size) to coordinate multi-user access to a file and a backup type program that copies files without checking anything. A manditory lock would stop the backup program. Les Mikesell
chip@ateng.ateng.com (Chip Salzenberg) (11/29/88)
According to shap@polya.Stanford.EDU (Jonathan S. Shapiro): >In SVR2, advisory locking was introduced via lockf(2) and fcntl(2). A >reading of the fine print will turn up a note indicating that this >will be changed to be mandatory locking at some unspecified point in >the future. Quite true; but the fine print also states that mandatory locking will take effect *only* for files with the setgid bit set, as is now done by System V Release 3. In contrast, Xenix 2.2 file locking is always mandatory for *all* files, regardless of their modes. This behavior is *not* SVID- compliant. >However, a program written to conform to the SVID will have no >problems in either case, because the warning in the SVID commentary >indicates that your program should make pessimistic assumptions about >deadlock. Deadlock has little to do with the difference between mandatory and advisory locking. In fact, "a program written to the SVID" (Smail 3.1, which I am alpha testing) *did* hang because of SCO 2.2 mandatory locking. Consider the scenario: A parent process with an exclusive lock on a file forks. (File locks are *not* inherited.) The child tries to read the file. The child, written for advisory locking, does not expect to hang. However, under SCO Xenix 2.2 mandatory locking, it *does* hang. Result: the child is waiting for the parent to unlock it; meanwhile, the parent is waiting for the child to exit! The deadlock involves more than just locking, so EDEADLOCK is *not* returned. Instead, both processes wait forever. Oh well. At least they fixed it in 2.3. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.