From owner-freebsd-arch Wed Oct 4 16:43:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843290.broadbandoffice.net [64.47.83.26]) by hub.freebsd.org (Postfix) with ESMTP id E669F37B676 for ; Wed, 4 Oct 2000 16:43:35 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.0/8.9.3) id e94NhRe31401; Wed, 4 Oct 2000 16:43:27 -0700 (PDT) (envelope-from dillon) Date: Wed, 4 Oct 2000 16:43:27 -0700 (PDT) From: Matt Dillon Message-Id: <200010042343.e94NhRe31401@earth.backplane.com> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores References: <200010042204.e94M4XH22892@netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :.. Unless I am missing something, I dont see any possibility of a race. And :even if there is one, the double-reparenting can be detected by an additional :pid test or generation numbers, or whatever. The point, Peter, is exactly the one I made in my last email: In order to justify this sort of optimization you have to run through a whole list of reasons to 'guarentee' that it will not cause a problem. What you have done is not added a simple optimization, but you have added a whole slew of code of UNDOCUMENTED code requirements on process reparenting. If down the line process reparenting changes at all, it could screw your optimization... even the smallest change to reparenting could destabillize the kernel. By introducing your optimization, you have created a whole slew of *REQUIREMENTS* on how the reparenting must act in order to not create new instabilities in the system. If at some future date reparenting changes (just as ptrace & debuggers changed it from the original 'process 1 always gets it' code), and breaks your SMP optimization, *NOBODY* will realize it until instabilities creep into the system, possibly months or years later, and it could take just as long to track it back down. It's that simple... these sort of optimizations only cause problems down the road. As an example I can point to the NFS code before I fixed it, which made so many assumptions about the buffer cache that even the most innocuous (and perfectly legal) change to the buffer cache code could break NFS. It is precisely these sorts of assumptions that were responsible for easily 20% of the bugs in the VM and NFS subsystems. Optimizations that may have worked when they were originally put in, but were so fragile that they broke over time due to changes made to seemingly unrelated interfaces within the kernel. It is NOT WORTH IT. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message