Date: Thu, 5 Jul 2001 20:35:58 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Alfred Perlstein <bright@sneakerz.org> 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: <Pine.BSF.4.33.0107052034040.31946-100000@herring.nlsystems.com> In-Reply-To: <20010705131757.E929@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Jul 2001, 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. I think the main argument here is that there is not enough information here to justify this particular optimisation. Lets wait until the implementation is nearer to being finished before worrying about this kind of micro-optimisation. -- 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.0107052034040.31946-100000>