threads/118910: Multithreading problem

[Daniel Eischen]

On Fri, 21 Dec 2007, David Xu wrote:

> Daniel Eischen wrote:
>> On Fri, 21 Dec 2007, David Xu wrote:
>> 
>>> The kernel condition variable implementation is problematic, a
>>> thread sleeping on a condition variable does not raise its priority
>>> to some I/O priority, but most code will raise thread's priority to some
>>> level with msleep(). The code in sound driver use lots of cv_broadcast
>>> call(), it does not raise thread priority, this causes the music player
>>> does not have more chances to do I/O while other I/O bound applications
>>> will have.
>>> 
>>> The kernel condition variable also causes top() to display incorrect
>>> priority because cv_wait does not update the priority but it is updated
>>> by cv_broadcastpri() which is too late for top to display.
>>> 
>>> The kernel condition variable's initialization function should accept
>>> a thread priority parameter, and all thread sleep on the condition
>>> variable should use the priority.
>> 
>> While your hypothesis of what is happening may be correct, I don't
>> think the solution is quite right.  msleep() has to go away, at
>> least the priority parameter does.  The kernel should be scheduling
>> based on thread priorities that are not artificially elevated by
>> parameters to msleep.
>> 
>> The kernel CV and mutexes initialization functions should accept
>> something like Solaris interrupt cookies (see mutex_init() and
>> cv_init() in Solaris).  All mutexes/CVs used by interrupt code
>> should initialize their CVs and mutexes with something like this.
>> I don't think they should be using a priority directly.
>> 
>
> Oh, I don't want to change BSD's behavior, the FreeBSD in the past years
> does raise thread priority while sleeping, if msleep does not raise
> thread priority, I don't know if FreeBSD will still work as normal, by
> the way, your idea is a big change.

I don't think it is as big a change as you think it is.  We already
have several layers of priorities (interrupt, time-share, idle, ?).
All threads belong to these classes.  As long as priority inheritence
works, there should be no problems.  The problems seem to occur when
we try to inject artificial priorities into threads, like using
msleep().  I think we are better off just letting threads run based
on their own base priority and whatever their inherited priority is.

-- 
DE