From owner-freebsd-stable Thu Apr 25 16:29:32 2002 Delivered-To: freebsd-stable@freebsd.org Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by hub.freebsd.org (Postfix) with ESMTP id 49FB637B41A for ; Thu, 25 Apr 2002 16:29:27 -0700 (PDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g3PNTRg04094; Thu, 25 Apr 2002 16:29:27 -0700 (PDT) Date: Thu, 25 Apr 2002 16:29:27 -0700 From: JJ Behrens To: freebsd-stable@FreeBSD.ORG, Erik Trulsson , Matthew Dillon , Joe Greco Cc: Matthew Dillon , Joe Greco Subject: Re: kernel trap 9 with interrupts disabled Message-ID: <20020425162927.C1444@alicia.nttmcl.com> Mail-Followup-To: JJ Behrens , freebsd-stable@FreeBSD.ORG, Erik Trulsson , Matthew Dillon , Joe Greco References: <200204251836.NAA41191@aurora.sol.net> <200204252115.g3PLF6c07119@apollo.backplane.com> <20020425153121.F3601@alicia.nttmcl.com> <20020425230656.GB10349@student.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20020425230656.GB10349@student.uu.se>; from ertr1013@student.uu.se on Fri, Apr 26, 2002 at 01:06:56AM +0200 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Almost, but not quite. In your scenario the low-priority task would > get to run since the high-priority task is blocked and would thus > eventually release the resource. No deadlock, no problem. > > The classic priority inversion that I have heard about is the following > scenario: > > Three processes of low, medium and high priority respectively. > The low-priority task locks some resource. Before this resource is > released both the medium-priority and the high-proiority task starts to > run. Since these have higher priority the low-priority task doesn't get > any CPU. The medium-priority task is CPU-intensive and uses all > CPU-time it gets (but it won't get any while the HP-task is running.) > Eventually the high-priority task tries to lock the resource that the > low-priority task is holding. The high-priority task is then blocked > and the medium-priority task gets to run. > > Now the high-priority task is blocked waiting for the resource that the > low-priority task is holding. The LP-task does not get to run since the > MP-task has higher priority and thus can't release the resource. > > This means that the priority between the HP task and the MP task has in > effect been inverted, since the medium priority task blocks the > high-priority task from running even if there is no resource that both > of them are trying to lock. > > The problem is that when the high-priority task got blocked trying to > acquire the resource that the low-priority task held it effectively > inherited the priority of the low-priority task and can therefore be > preempted by the medium-priority task. > > > To get a priority inversion like this one needs at least three tasks > with different priorities. Ah, yes. I stand corrected :) Thanks, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message