From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 07:40:40 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B314716A418; Fri, 21 Dec 2007 07:40:40 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A705913C468; Fri, 21 Dec 2007 07:40:40 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBL7ebPk033189; Fri, 21 Dec 2007 07:40:38 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476B6E35.508@freebsd.org> Date: Fri, 21 Dec 2007 15:41:41 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Daniel Eischen References: <200712210700.lBL707MZ002071@freefall.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2007 07:40:40 -0000 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