Date: Wed, 19 Mar 2008 22:19:58 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, David Xu <davidxu@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Getting rid of the static msleep priority boost Message-ID: <Pine.GSO.4.64.0803192204280.6239@sea.ntplx.net> In-Reply-To: <200803191526.56761.jhb@freebsd.org> References: <20080307020626.G920@desktop> <20080318235125.G910@desktop> <20080319172344.GX67856@elvis.mu.org> <200803191526.56761.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Mar 2008, John Baldwin wrote: > On Wednesday 19 March 2008 01:23:44 pm Alfred Perlstein wrote: >> * 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? > > Right now we let people invoke cv_wakeup/signal w/o holding the lock. I > actually took the thread queue out of condvar's back when doing the original > sleep queue stuff since it is cheaper space wise. Instead of each possible > condvar having its own set of queue pointers you just have a set of queue > pointers for each thread in the system. Similar to only have a turnstile per > thread rather than per lock. In regards to why should we use cv_wait() instead of msleep()'s, the mutex/cv operations are more POSIX/pthreads-like with a simpler set of arguments. Solaris for example does not have msleep() nor anything like that I can see, it uses similar mutex/cv operations as part of its kernel ABI (DDI/DKI). I don't think there is a problem in allowing cv_signal() to be called without holding the lock, but it's nice that cv_wait() requires the lock - this is the same behavior as in pthreads and Solaris primitives. Perhaps there are no performance differences, but the cv/mutex primitives are a nice clean interface that most everyone understands. If you are going to write a professional OS from the ground up, I doubt you are going to have anything as convoluted as msleep() as part of your kernel API/ABI. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0803192204280.6239>