Date: Thu, 5 Jul 2001 17:55:03 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Matthew Jacob <mjacob@feral.com> Cc: John Baldwin <jhb@FreeBSD.org>, Matt Dillon <dillon@earth.backplane.com>, <cvs-all@FreeBSD.org>, <cvs-committers@FreeBSD.org>, Jake Burkholder <jake@FreeBSD.org> Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <Pine.BSF.4.33.0107051748570.31459-100000@herring.nlsystems.com> In-Reply-To: <20010705091047.C37950-100000@wonky.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0107051748570.31459-100000>