From owner-freebsd-hackers Mon Aug 23 8:33:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id D26B2156E5 for ; Mon, 23 Aug 1999 08:33:53 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id LAA88167; Mon, 23 Aug 1999 11:29:42 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 23 Aug 1999 11:29:42 -0400 (EDT) From: Chuck Robey To: Ville-Pertti Keinonen Cc: Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Mandatory locking? In-Reply-To: <86zoziwp88.fsf@not.demophon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23 Aug 1999, Ville-Pertti Keinonen wrote: > > grog@lemis.com (Greg Lehey) writes: > > > Again, if we have two concurrent transactions, we stand to gain money: > > the updated balance is likely not to know about the other transaction, > > and will thus "forget" one of the deductions. > > > Now I suppose you're going to come and say that this is bad > > programming, and advisory locking would do the job if the software is > > written right. Correct. You could also use the same argument to say > > that memory protection isn't necessary, because a correctly written > > program doesn't overwrite other processes address space. It's the > > The difference is that if a program has privileges to screw up > whatever you are protecting, it can do so even if you do have > mandatory locking, simply by functioning incorrectly when it does gain > access to the data. > > And even without otherwise incorrect behavior, if you have a program > that doesn't use any locking and another one that uses mandatory > locking to prevent races with the non-locking program, the mere > existence of the locking program does not prevent multiple non-locking > programs from generating similar conditions. That's very odd, I thought the idea behind mandatory locking was to completely eliminate the possibility that a program could do what you're saying; all programs would *mandatorily* be forced to do locking to access the resource. It's the advisory locking that allows the scenario you paint. I think mandatory locking should exist, but only be available to root. If a program needs this, it must run with root privs, so that ordinary users cannot wedge the machine, but (as usual) root can shoot himself in the foot (traditional Unix methodology). > > (I'm not opposed to mandatory locking in principle, but I don't find > your reasoning very convincing.) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message