Date: Sun, 8 Jul 2001 11:04:49 +0930 From: Greg Lehey <grog@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: Alfred Perlstein <bright@sneakerz.org>, "Justin T. Gibbs" <gibbs@scsiguy.com>, John Baldwin <jhb@FreeBSD.org>, Jake Burkholder <jake@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Matthew Jacob <mjacob@feral.com>, Doug Rabson <dfr@nlsystems.com> Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <20010708110449.E75626@wantadilla.lemis.com> In-Reply-To: <200107060214.f662ElT61708@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Jul 05, 2001 at 07:14:47PM -0700 References: <XFMail.010705123747.jhb@FreeBSD.org> <200107052228.f65MSeU64741@aslan.scsiguy.com> <20010705174135.A79818@sneakerz.org> <200107060214.f662ElT61708@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 5 July 2001 at 19:14:47 -0700, Matt Dillon wrote: > >> * Justin T. Gibbs <gibbs@scsiguy.com> [010705 17:28] wrote: >>>> 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. >>> >>> This window exists anyway. The locked mutex it not passed to the woken >>> up thread, so there will always be a race between the woken up thread >>> acquiring the mutex and some other thread on some other CPU acquiring it >>> first and making the wakeup invalid. >> >> >> Y'know this sorta got me thinking about something else, shouldn't the >> wakeup() calls for most exclusive locks use wakeup_one? I know >> wakeup_one() hoses priority, but for the locks in things like vnodes >> and the pager locks, shouldn't we do a wakeup_one() since it is an >> exclusive lock? >> >> -- >> -Alfred Perlstein [alfred@freebsd.org] > > I would not recommend using wakeup_one until 5.2ish. A mistake could > result in hard-to-find system lockups. I would not recommend using wakeup_one. It has the potential to hang the system. One of the tradeoffs in the sleep/wakeup paradigm is that you wait on an arbitrary address. This works fine as long as you wake up *every* process. But consider two independent subsystems which wait on the same address. wakeup_one wakes the first waiter on the list, which happens to belong to the other subsystem. It checks its environment and goes back to sleep. Bingo! The first subsystem has lost a wakeup. This isn't a theoretical situation: it happened in Vinum. The solution is to guarantee that two subsystems don't wait on the same address. I don't see that this is addressed by the current condition variable implementation, but I'm prepared to be taught otherwise. In this connection, more on the Vinum implementation: the code is in lockrange() in vinumlock.c. It implements locking for a potentially very large number of bands in a RAID-5 volume, and it sleeps on the band address. The only alternative I can see at the moment is to create a large number of mutex locks, one per band, which could be very expensive. If anybody has a better idea after looking at the code, I'd be interested. Greg -- See complete headers for address and phone numbers 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?20010708110449.E75626>