From owner-freebsd-hackers Wed Aug 25 3:44:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 875CA15879 for ; Wed, 25 Aug 1999 03:44:06 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id NAA59665; Wed, 25 Aug 1999 13:42:17 +0300 (EEST) (envelope-from will) To: wes@softweyr.com (Wes Peters) Cc: hackers@freebsd.org Subject: Re: Mandatory locking? References: <19990823231130.A16133@netmonger.net> <37C3890B.7AD1E44F@softweyr.com> From: Ville-Pertti Keinonen Date: 25 Aug 1999 13:42:16 +0300 In-Reply-To: wes@softweyr.com's message of "25 Aug 1999 09:14:26 +0300" Message-ID: <86pv0ccfau.fsf@not.demophon.com> Lines: 41 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG wes@softweyr.com (Wes Peters) writes: > And how many programmers with nearly (or more than) two decades of UNIX > experience it takes to convince someone it really is useful. It should only take one, as long as the arguments made are not bogus. IMHO Greg made some very silly arguments (or at least used some very stupid examples) for mandatory locking and never answered my points regarding them. (The arguments of some of the ones opposing mandatory locking have been equally silly.) I *do* agree that mandatory locking *can* be useful, but the usefulness is not nearly as broad as some people seem to be implying, and advisory locking is not as useless as some claim. The most significant advantage I see with mandatory locking over advisory locking is guaranteeing atomicity for things done by programs that do use locking. This only protects the data when programs that access the same data without locking don't need locking, which generally means that they either don't need to modify the data or that there can't be multiple instances of those other programs *and* the modifications made are themselves atomic (can't be read-modify-write, or even multiple writes if consistency is required). This is a somewhat limited set of cases. If anyone can come up with a counter-example, please present it. Locking entire files, in addition to ranges, would seem to me to be of further benefit, as it would allow properly locking programs to fully protect against any single non-locking program which, like Greg's cat example, would presumably be run interactively and thus would require explicit stupidity to create additional races. Locking entire files is also the only way to ensure that non-locking programs can even see the file in a consistent state. As a special case, mandatory locking could also be useful in ensuring long-term exclusive access to some set of data, but this seems like something that should be done using file permissions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message