threads/118910: Multithreading problem

[David Xu]

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.

Regards,
David Xu