Date: Wed, 4 Oct 2000 16:43:27 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <200010042343.e94NhRe31401@earth.backplane.com> References: <200010042204.e94M4XH22892@netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:.. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010042343.e94NhRe31401>