Getting rid of the static msleep priority boost

Alfred Perlstein alfred at freebsd.org
Wed Mar 19 17:25:08 UTC 2008


* Jeff Roberson <jroberson at 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


More information about the freebsd-arch mailing list