From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 08:25:04 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 40E8C16A41A; Fri, 21 Dec 2007 08:25:04 +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 3297D13C447; Fri, 21 Dec 2007 08:25:04 +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 lBL8P1QF065684; Fri, 21 Dec 2007 08:25:02 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476B789E.4040009@freebsd.org> Date: Fri, 21 Dec 2007 16:26:06 +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> <476B6E35.508@freebsd.org> <476B7476.3010509@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 08:25:04 -0000 Daniel Eischen wrote: > 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. > kernel mutex is already priority inheritence, the spin lock mutex looks like a priority protected mutex which raises thread priority to highest possible(critical section), and can not be preempted. so there is no priority problem in mutex. The only problem I can think of is semaphore-like msleep/wakeup pair which does not do priority inheritance, if a higher priority thread is blocked in msleep, priority of another thread holding the resources is not boosted.