Skip site navigation (1)Skip section navigation (2)
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>