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