From owner-freebsd-hackers Fri Jun 7 21:08:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA02212 for hackers-outgoing; Fri, 7 Jun 1996 21:08:08 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA02123; Fri, 7 Jun 1996 21:08:02 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA02519; Fri, 7 Jun 1996 22:07:40 -0600 Date: Fri, 7 Jun 1996 22:07:40 -0600 From: Nate Williams Message-Id: <199606080407.WAA02519@rocky.sri.MT.net> To: Michael Hancock Cc: Nate Williams , Terry Lambert , hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD-current@FreeBSD.org Subject: Re: The -stable problem: my view In-Reply-To: References: <199606080221.UAA02108@rocky.sri.MT.net> Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Terry proposes a set of tools to help enforce the policy of always having > ^^^^^^ > > I said help not guarantee. The tools would help resolve reads while > commits are being done. Multiple reader/single writer locks are a cheap > effective way to do this. They wouldn't enforce or even help the policy. Multiple reader/single writer locks don't solve any significant problem we've faced. Why do something that limits the ability of developers to commit changes when the problem the fix happens .001% of the time? It's like making a loop that gets called once at initialization time 50% faster while you leave the sorting algorithm which takes up 95% of CPU time alone. It's doesn't buy you anything but a warm fuzzy feeling. Nate