From owner-cvs-all Thu Jul 5 12:44:23 2001 Delivered-To: cvs-all@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id B3CD837B405; Thu, 5 Jul 2001 12:44:12 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 15IF3e-000IQ0-0V; Thu, 5 Jul 2001 20:45:02 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f65Jgu732113; Thu, 5 Jul 2001 20:42:56 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 5 Jul 2001 20:42:56 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: Alfred Perlstein , Jake Burkholder , , , Matt Dillon , Matthew Jacob 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 On Thu, 5 Jul 2001, John Baldwin wrote: > > 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. I understand that. I'm suggesting that the code calling wakeup() should be holding the lock and release it *after* the wakeup(). I don't really have strong feelings about this but I can certainly see the point of the people who are arguing that this is not needed. -- 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