Date: Thu, 5 Jul 2001 19:14:47 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@sneakerz.org> Cc: "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: <200107060214.f662ElT61708@earth.backplane.com> References: <XFMail.010705123747.jhb@FreeBSD.org> <200107052228.f65MSeU64741@aslan.scsiguy.com> <20010705174135.A79818@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:* 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.
-Matt
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?200107060214.f662ElT61708>