threads/118910: Multithreading problem

[Daniel Eischen]

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.

-- 
DE