Getting rid of the static msleep priority boost

[Jeff Roberson]

On Wed, 19 Mar 2008, Daniel Eischen wrote:

> On Wed, 19 Mar 2008, John Baldwin wrote:
>
>> On Wednesday 19 March 2008 01:23:44 pm Alfred Perlstein wrote:
>>> * 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?
>> 
>> 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.

One real obstacle to converting all locations to cv_* is the lack of 
support for anything other than mtx def mutexes in the cv api.  It also 
just doesn't seem like a good use of developer resources regardless of how 
you feel about msleep.

Also, in regards to interlocking with the user supplied lock; the lock 
that we interlock with for scheduling purposes must be a spinlock. 
Therefore we can't use just any user supplied lock to protect the sleepq 
chain.

Thanks,
Jeff

>
> -- 
> DE
>