Date: Fri, 21 Dec 2007 07:00:07 GMT From: David Xu <davidxu@FreeBSD.org> To: freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem Message-ID: <200712210700.lBL707MZ002071@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR threads/118910; it has been noted by GNATS. From: David Xu <davidxu@FreeBSD.org> To: Kuteynikov Dmitriy <kuteynikov@gmail.com> Cc: freebsd-gnats-submit@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712210700.lBL707MZ002071>