From owner-freebsd-hackers Mon Aug 23 9:52:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 04D421568C; Mon, 23 Aug 1999 09:52:25 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA23114; Tue, 24 Aug 1999 01:51:48 +0900 (JST) Message-ID: <37C174F5.2D8AEEB1@newsguy.com> Date: Tue, 24 Aug 1999 01:21:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Greg Lehey Cc: 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > all done in the kernel anyway. In userland, we'd use a different > example: > > I make a number of financial transactions over the Internet. In > each case, the system checks my account balance, transfers the money > and deducts it from my account: > > 1. Check balance. > 2. Perform transfer. > 3. Write updated balance back. > > 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 > same thing: file protection belongs in the kernel. Well, I'd say advisory lock does the job if the software is written right, and if the software is not written right, mandatory locking won't help. Let's give an example. You right a program using mandatory locking making access to a file. I write an "incorrect" program accessing that file. I garantee you that the file is going to be screwed up, because I intend to write random output to it as soon as I get access to it. After all, if I'm incorrect, I'm allowed to do anything. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message