Date: Wed, 19 Mar 2008 10:23:44 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Daniel Eischen <deischen@FreeBSD.org>, arch@FreeBSD.org, David Xu <davidxu@FreeBSD.org> Subject: Re: Getting rid of the static msleep priority boost Message-ID: <20080319172344.GX67856@elvis.mu.org> In-Reply-To: <20080318235125.G910@desktop> References: <20080307020626.G920@desktop> <Pine.GSO.4.64.0803071114100.1950@sea.ntplx.net> <47E0CCC4.8040503@freebsd.org> <20080318235125.G910@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@chesapeake.net> [080319 02:51] wrote: > On Wed, 19 Mar 2008, David Xu wrote: > > >Daniel Eischen wrote: > > > >>I'm not sure if any of the above remove the priority from the API, > >>but it would be nice to get rid of msleep totally and replace it > >>with an equivalent cv_wait(). > >> > > > >And create sleep queue in each cv to get rid of shared sleep queue > >lock ? > > Some spinlock is required to interlock with the scheduler lock via > thread_lock(). So I don't think you can get rid of that layer. You also > wouldn't want to have the cost of a 'struct sleepqueue' everywhere you > want a msleep/condvar. > > I personally don't see any real advantage to using condvar everywhere. > The only thing you really get is protection against spurious wakeups. In theory can't you protect the waitq hung off of condvars with the mutex/spinlock used for the condvar instead of a global (hashed) lock on the global waitq? (although doing a condvar_signal/broadcast without the lock would require that the internal code reacquire the lock) -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080319172344.GX67856>