From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 07:36:25 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C468116A418; Fri, 21 Dec 2007 07:36:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF2113C45A; Fri, 21 Dec 2007 07:36:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lBL7aOsp010016; Fri, 21 Dec 2007 02:36:24 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 21 Dec 2007 02:36:24 -0500 (EST) Date: Fri, 21 Dec 2007 02:36:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200712210700.lBL707MZ002071@freefall.freebsd.org> Message-ID: References: <200712210700.lBL707MZ002071@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/118910: Multithreading problem X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2007 07:36:25 -0000 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