Date: Sun, 08 Jul 2001 07:06:48 -0400 From: Sergey Babkin <babkin@bellatlantic.net> To: Greg Lehey <grog@FreeBSD.org> Cc: Matt Dillon <dillon@earth.backplane.com>, 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: <3B483EC8.274941E@bellatlantic.net> References: <XFMail.010705123747.jhb@FreeBSD.org> <200107052228.f65MSeU64741@aslan.scsiguy.com> <20010705174135.A79818@sneakerz.org> <200107060214.f662ElT61708@earth.backplane.com> <20010708110449.E75626@wantadilla.lemis.com> <3B47E2EF.3022DF3F@bellatlantic.net> <20010708143303.Z80862@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote: > > On Sunday, 8 July 2001 at 0:34:55 -0400, Sergey Babkin wrote: > > Greg Lehey wrote: > >> > >>>> 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. > > > > Hm, my understanding is that the intended "standard" way of using the > > likes of wakeup_one (such as sVr4.mp condition variable non-broadcast Oops, here I mixed up the conditions and the synchronisation(?) variables (those with calls named SV_*). I really meant the SVs. > > signalling) is that after the woken up process/thread completes its > > work it _must_ check if anybody else is sleeping on the same > > condition and wake up the next sleeper. > > Hmm. But I haven't seen that documented anywhere. It also places the > responsibility in the wrong place IMO. I think the Schimmel's book describes that but can't say for sure if it states it explicitly as the pnly use. Probably it would be good to put it in the man page too. > > The idea is that the conditional variable protects a resource that > > may only be used by one process at a time, so to avoid waking up all > > the potential herd of sleeping processes only to get all of them but > > one to check the condition and go to sleep again, only one process > > is woken up at a time, and after it's done it must wake up the next > > one. I'd say that any other use of such non-broadcast wakeup is > > probably bogus. > > The problem is that you need to choose your condition pretty > carefully. I suppose that's possible. I haven't thought it through > yet. The general rule here is "when in doubt, use broadcast wakeups". In the worst case you only lose efficiency and even that only if there really are many processses waiting on this event, and only on an SMP machine. But an use of a non-broadcast wakeup where it's not appropriate puts the program's correctness at risk. BTW, the sVr4 "conditions" are an optimisation for an often used case, the producer-consumer relation. It works kind of like a semaphore. -SB 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?3B483EC8.274941E>