Date: Thu, 5 Jul 2001 20:42:56 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Alfred Perlstein <bright@sneakerz.org>, Jake Burkholder <jake@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>, Matt Dillon <dillon@earth.backplane.com>, Matthew Jacob <mjacob@feral.com> Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <Pine.BSF.4.33.0107052040450.31946-100000@herring.nlsystems.com> In-Reply-To: <XFMail.010705123747.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Jul 2001, John Baldwin wrote: > > On 05-Jul-01 Alfred Perlstein wrote: > > * Doug Rabson <dfr@nlsystems.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0107052040450.31946-100000>