From owner-freebsd-hackers Tue Aug 24 9:30:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id E542615880; Tue, 24 Aug 1999 09:27:18 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JHZ5-00043m-00; Tue, 24 Aug 1999 08:28:43 -0600 Message-ID: <37C2AC18.28A9DE08@softweyr.com> Date: Tue, 24 Aug 1999 08:28:40 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Masto Cc: Garance A Drosihn , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com> <19990823223645.A14001@netmonger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Masto wrote: > > > The thing about well-intentioned but incorrect locking code is that > > it will appear to work fine, until it trips over the one code path > > where it forgets to lock some file that it should have locked. And > > even then, the code will "work" just fine, until multiple processes > > are accessing that file at the same time. > > > > I think it is appropriate for an operating system to provide an option > > such that *it* (the system) will enforce the locking, and not have to > > trust that all code-paths in all programs will do the right thing > > WRT advisory locking. > > Dunno about that.. if you're using advisory locking, you know to say > "lock the file, then read the data, do your calculation, write it out, > and unlock". This manditory locking sounds like an invitation for > disaster. "I don't need to pay attention to the details because > the kernel will take care of it for me." Wrong paradigm. Look at it from the lockers standpoint: "Even if other processes don't do locking, they won't be able to screw me because I've locked the critical part of the file." > Actually, I don't really understand the paradigm. Two processes need > to safely update a file, so one of them aquires a mandatory lock, and > the other.. uh.. just blocks trying to open the file? No, the locks are not per-file. You can lock multiple arbitrary byte ranges. Any file trying to write (shared lock) and/or read (exclusive lock) will be blocked until the lock is released. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message