From owner-cvs-all Thu Jul 5 12:38:11 2001 Delivered-To: cvs-all@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with SMTP id 8FD5F37B406 for ; Thu, 5 Jul 2001 12:37:54 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7894 invoked from network); 5 Jul 2001 19:37:50 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Jul 2001 19:37:50 -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: <20010705131757.E929@sneakerz.org> Date: Thu, 05 Jul 2001 12:37:47 -0700 (PDT) From: John Baldwin To: Alfred Perlstein Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Cc: Jake Burkholder , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Matt Dillon , Matthew Jacob , Doug Rabson 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 05-Jul-01 Alfred Perlstein wrote: > * Doug Rabson [010705 11:56] wrote: >> >> 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(). > > It's not a race, it's just an optimization to avoid this happening. > > Thread A locks a mutex, > Thread A determines it must wait for an event on the object protected > by the mutex and calls msleep(), > Thread B locks the mutex, > Thread B fiddles a structure and calls wakeup on it to signal > waiting 'A' that it can proceed. > > At this point there may be preemption, if Thread A now runs, it will > immediately block on the mutex again because B hasn't released it. > > This is avoided with mwakeup(). > > However, I'm not much of a fan of wakeup() being a premption point. It happens with SMP, too, not just preemption. The calls are an optimization to avoid problems with releasing the lock after the wakeup. The contention can be avoided if we release the lock before calling wakeup(), but doing that leaves a window open for another CPU to alter the data that the lock protects possibly invalidating the wakeup that then gets sent. These aren't preemption-only problems. Preemption just simulates the SMP environment (since another CPU can grab a process as soon as setrunqueue() completes), so things that preemption bring up are going to occur in a non-preemptive SMP kernel, as well. > -Alfred -- 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