From owner-cvs-all Thu Jul 5 9:56:33 2001 Delivered-To: cvs-all@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 10B9A37B403; Thu, 5 Jul 2001 09:56:21 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15ICPX-000Hc1-0Y; Thu, 5 Jul 2001 17:55:27 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f65Gt3731499; Thu, 5 Jul 2001 17:55:03 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 5 Jul 2001 17:55:03 +0100 (BST) From: Doug Rabson To: Matthew Jacob Cc: John Baldwin , Matt Dillon , , , Jake Burkholder Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ In-Reply-To: <20010705091047.C37950-100000@wonky.feral.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Jul 2001, Matthew Jacob wrote: > > > On Thu, 5 Jul 2001, Doug Rabson wrote: > > > On Wed, 4 Jul 2001, Matthew Jacob wrote: > > > > > > Imagine an interrupt between the wakeup and lock release. That would give > > > > plenty enough time for another CPU to grab the woken process and then block on > > > > the lock. > > > > > > John- show some numbers with even a 32 processor SGI that this happens > > > all that much. Yer reachin'.... > > > > I think that all John is saying that the possibility of taking an > > interrupt can make the size of the window large enough for another cpu (or > > for preemption on this cpu) to grab the woken process. > > > > I know from the original alpha port that in a buildworld, even 1-2 > > instruction windows can cause races. > > Of course. > > There are two issues we've been bruiting about. > > 1. "Safe is Safe. Unsafe isn't." > > If there's a window in wakeup, solving it by requiring the caller to > release a lock it holds in order for it to wake things up safely is > wrong, in my ill-informed opinion. > > One of the arguments so far for the new functions is to avoid some kind > of (vaguely stated) breakage window. I haven't been massively convinced > by the explanations so far. > > *Either the caller code is making incorrect assumptions or there's > something broken in the atomicity of the scheduler* Right. I'm not actually arguing for the existence of mwakeup() and friends. I can't yet see any race window that they close when compared to a code sequence which calls wakeup() followed by mtx_unlock(). > > 2. "Premature optimization is the root of all evil" - Donald Knuth Unless there is a real race window here, it does seem that we are micro-optimising here and I don't really see the point. > Scenario B: > > John's clearest comment: > > > but I can see the state of the subsytem being altered by another CPU > > "The Subsystem"... *Which* subsystem? > > > before the wakeup is delivered (since the lock is unlocked and we > > may preempt on lock release and thus alter the state of the locked > > subsytem before coming back to the original thread and doing the > > wakeup) resulting in possibly bogus wakeups being sent. Yuck. > > cpuX cpuY > signals cv > goes to run thread > > releases lock > > tries to run tries to run > thread, thread, > collides collides > > It seems to me that this should be a "cannot happen", or if it does > happen (as it would with something like broadcast interrupts), the code > the lock covers has to cope. This situation can't happen. The scheduler lock prevents this from happening. If two cpus can pick up a single thread, there is a serious problem in the scheduler (I don't think there is). > > Look- I'm not trying to argue for the sake of arguing. I was asking what > I think are very simple questions. I'll conclude from this exercise that > I really don't understand what the SMP implementors here are trying to > accomplish and drop it. I don't agree with creeping featurism, and, > *wince*, I kind of have to agree with the other Matt about this not > addressing the real problem set, but it's also quite possible that I > have no clue as to what's going as well. Sorry for raising a ruckus. I think I probably agree with you both (at least about the featurism, not about the perceived evils of preemption). We should not be trying to micro-optimise at least until we have measured the problem. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message