From owner-freebsd-hackers Wed Aug 25 12:21: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 20B3C15364; Wed, 25 Aug 1999 12:20:16 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA02433; Wed, 25 Aug 1999 12:19:39 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAANWaySe; Wed Aug 25 12:19:33 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA09167; Wed, 25 Aug 1999 12:19:47 -0700 (MST) From: Terry Lambert Message-Id: <199908251919.MAA09167@usr08.primenet.com> Subject: Re: Mandatory locking? To: dcs@newsguy.com (Daniel C. Sobral) Date: Wed, 25 Aug 1999 19:19:46 +0000 (GMT) Cc: drosih@rpi.edu, grog@lemis.com, phk@critter.freebsd.dk, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu In-Reply-To: <37C2ABE4.B2C12DA4@newsguy.com> from "Daniel C. Sobral" at Aug 24, 99 11:27:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. Which is why you perform unit testing, itegration testing, and full branch path validation, if you are a professional software engineer engaging in due dilligence. Unfortunately, most professional software engineers are only permitted by their management to engage in due dilligence when the softwar being worked on is part of a life-support system of some kind (e.g. the software that runs on the microcontroller in your cars anti-lock braking system). Most software malfunctions are the result of either software engineer unprofessionalism or management unprofessionalism, not because "software is magic" and not because "software is this amorphorous thing" and not because "the software is too complex for one mind to grasp all of it". Anyone who tells you any different is either lying or a hardware engineer. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message