threads/118910: Multithreading problem

[David Xu]

The following reply was made to PR threads/118910; it has been noted by GNATS.

From: David Xu <davidxu at FreeBSD.org>
To: Kuteynikov Dmitriy <kuteynikov at gmail.com>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: threads/118910: Multithreading problem
Date: Fri, 21 Dec 2007 14:56:35 +0800

 Kuteynikov Dmitriy wrote:
 >> Number:         118910
 >> Category:       threads
 >> Synopsis:       Multithreading problem
 >> Confidential:   no
 >> Severity:       serious
 >> Priority:       high
 >> Responsible:    freebsd-threads
 >> State:          open
 >> Quarter:        
 >> Keywords:       
 >> Date-Required:
 >> Class:          sw-bug
 >> Submitter-Id:   current-users
 >> Arrival-Date:   Thu Dec 20 23:10:01 UTC 2007
 >> Closed-Date:
 >> Last-Modified:
 >> Originator:     Kuteynikov Dmitriy
 >> Release:        7.0-BETA2
 >> Organization:
 > MEPHI
 >> Environment:
 > FreeBSD av113962 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Fri Nov  2 16:47:33 UTC 2007     root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 >> Description:
 > I have average computer: Athlon XP 2000+ with 1024 Mb RAM. When I listen music (in Rhythmbox) and move a window of any application for 3 or more seconds music stops to play. I haven't noticed this problem in previous releases. Is it multithreading problem in kernel?
 >> How-To-Repeat:
 > pkg_add -r fluxbox
 > pkg_add -r rhythmbox
 > startx
 > fluxbox
 > rhythmbox
 > Turn on music and move xterm window for some seconds.
 >> Fix:
 > 
 > 
 >> Release-Note:
 >> Audit-Trail:
 >> Unformatted:
 
 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.
 
 Regards,
 David Xu