From owner-cvs-all Wed Jul 4 10:42:52 2001 Delivered-To: cvs-all@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 8F94737B409; Wed, 4 Jul 2001 10:42:46 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f64HgjS12464; Wed, 4 Jul 2001 10:42:45 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 4 Jul 2001 10:42:45 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: John Baldwin Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ In-Reply-To: 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 > > > > > > 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