From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 08:16:17 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 60AA716A468; Fri, 21 Dec 2007 08:16:17 +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 275FD13C442; Fri, 21 Dec 2007 08:16:17 +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 lBL8GGaj024604; Fri, 21 Dec 2007 03:16:16 -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 03:16:16 -0500 (EST) Date: Fri, 21 Dec 2007 03:16:15 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <476B7476.3010509@freebsd.org> Message-ID: References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B6E35.508@freebsd.org> <476B7476.3010509@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 08:16:17 -0000 On Fri, 21 Dec 2007, David Xu wrote: > Daniel Eischen wrote: > >> I don't think it is as big a change as you think it is. We already >> have several layers of priorities (interrupt, time-share, idle, ?). >> All threads belong to these classes. As long as priority inheritence >> works, there should be no problems. The problems seem to occur when >> we try to inject artificial priorities into threads, like using >> msleep(). I think we are better off just letting threads run based >> on their own base priority and whatever their inherited priority is. >> > > For test purpose, you may try to ignore thread priority parameter > in msleep(), I didn't test this, but it does change the FreeBSD > behavior. I don't know any side effect since I am unable to test > all applications in the world, maybe you can start a project to hack > it ? I'll take a look at trying that. I should be able to figure out how to get msleep to ignore the priority. But I think the missing piece is the interrupt routines - they need to create their mutexes and CVs so that they are more like priority ceiling mutexes. Any thread (even non-interrupt threads) that takes one of these mutexes needs to have its priority raised as well as blocking the interrupt (for fast interrupts anyway) until the mutex is released. -- DE