Date: Thu, 5 Jul 2001 13:17:57 -0500 From: Alfred Perlstein <bright@sneakerz.org> To: Doug Rabson <dfr@nlsystems.com> Cc: Matthew Jacob <mjacob@feral.com>, John Baldwin <jhb@FreeBSD.org>, Matt Dillon <dillon@earth.backplane.com>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder <jake@FreeBSD.org> Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <20010705131757.E929@sneakerz.org> In-Reply-To: <Pine.BSF.4.33.0107051748570.31459-100000@herring.nlsystems.com>; from dfr@nlsystems.com on Thu, Jul 05, 2001 at 05:55:03PM %2B0100 References: <20010705091047.C37950-100000@wonky.feral.com> <Pine.BSF.4.33.0107051748570.31459-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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. -Alfred 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?20010705131757.E929>