Date: Wed, 4 Jul 2001 10:42:45 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.org> Cc: 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.21.0107041036590.11969-100000@beppo> In-Reply-To: <XFMail.010704094047.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > I'm a bit confused by this last statement. Wakeups should never be lost > > not matter what. > > If you released the lock before acquiring sched_lock in wakeup() > there is a window during which you can lose a wakeup. Well, now > that I play with this in my head, I can't think of a wakeup being > missed, My point. > but I can see the state of the subsytem being altered by another CPU > 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. Sigh. > > > I can see that it's possible you could get contention if the cv_signal > > or wakeup causes a reschedule on another CPU right away. Is there any > > empirical measurements showing this happening? > > If a CPU is idle this can easily happen. In a fully preeemptive > kernel where wakeup (well, setrunqueue) will switch to the new > process that it just woke up if it is higher priority than the > current one it can easily happen as well. Well, it seemed like creeping featurism, but it is probably okay. Although it *does* seem to me that if you do: wakeup unlock in your code, I find it hard to believe that you will contention *after* the wakeup but before the unlock except in the pre-emption case. That's why I asked for some empirical data. -matt 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.21.0107041036590.11969-100000>