From owner-cvs-all Wed Jul 4 11:49:23 2001 Delivered-To: cvs-all@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with SMTP id 93D2037B403 for ; Wed, 4 Jul 2001 11:49:04 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 71409 invoked from network); 4 Jul 2001 18:49:03 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Jul 2001 18:49:03 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200107041838.f64Ic4V46525@earth.backplane.com> Date: Wed, 04 Jul 2001 11:49:01 -0700 (PDT) From: John Baldwin To: Matt Dillon Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, Jake Burkholder , Matthew Jacob 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 04-Jul-01 Matt Dillon wrote: >:Releasing the lock before the wakeup leaves a window open (interrupts can >:make >:small windows into large ones) during which the state of the subsystem can >:change before the wakeup is delivered, possibly resulting in a bogus wakeup >:being sent. However, I'm not sure that this window is actually a problem, >:and >:I'm less convinced than when mwakeup() was first proposed. > > We use this trick (clear variable then wakeup and who cares if there is > a window there or not) all over the codebase. If the window isn't a problem, then releasing the lock before wakeup/cv_signal/cv_wakeup is fine. >:> In the non-preemptive case, on a MP system, the scheduling overhead >:> will take far longer then it takes the original thread to release the >:> mutex so it does not matter whether the mutex is released before or >:> after >:> the wakeup. >: >:Unless you get an interrupt in between the wakeup and lock release. > > A window which has no real effect other then to cause one wakeup out > of several million (or billion) to delay another thread. That verses > the overhead of doing some sort of interlock on every single wakeup > means you are actually making things worse with the interlock. There is no overhead with the interlock silly. We have to grab the sched_lock in wakeup() no matter what, and whether or not we hold a sleep lock has no bearing on that at all. We also have to release the other mutex at some point in time, and it takes just as long to release it if we hold the sched_lock than if we don't hold it. What overhead? All we are doing is changing the location that the lock is dropped. >:> My assertion is that mwakeup() is solving a problem created by the >:> preemption in the first place and that assertion still holds true. >: >:No. If you must hold the lock across wakeup(), then you have the same >:problem >:with contending on the lock in the SMP case as in the preemptive case. If >:you >:release the lock before wakeup(), then both cases each have the same window >:open during which the state of the subsystem can change between the lock >:release and the wakeup being delivered. Preemption is an SMP environment on >:a >:UP system. The problems encountered by preemption will be encountered in SMP >:systems anyway. > > No, if you wakeup a thread and then release the mutex in a non-preemptive > case, even if you have multiple idle CPUs available, the scheduling and > switching overhead in the thread being woken up will be vastly greater > then the time it takes for the caller to release the mutex. So by the > time the newly woken up thread actually checks the mutex, it will have > already been released in the vast majority of cases. The cache > mastership > changes between the two cpu's alone is probably sufficient to cover the > time. 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. > -Matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message