From owner-freebsd-arch@FreeBSD.ORG Mon Oct 4 17:34:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D2A316A4CF for ; Mon, 4 Oct 2004 17:34:42 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id DCAE943D48 for ; Mon, 4 Oct 2004 17:34:41 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 29366 invoked by uid 89); 4 Oct 2004 17:34:40 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 4 Oct 2004 17:34:40 -0000 Received: (qmail 29334 invoked by uid 89); 4 Oct 2004 17:34:40 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 4 Oct 2004 17:34:40 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i94HYcmt044759; Mon, 4 Oct 2004 13:34:39 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: John Baldwin In-Reply-To: <200410041131.35387.jhb@FreeBSD.org> References: <1095468747.31297.241.camel@palm.tree.com> <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1096911278.44307.17.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 04 Oct 2004 13:34:38 -0400 Content-Transfer-Encoding: 7bit cc: Peter Holm cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 17:34:42 -0000 On Mon, 2004-10-04 at 11:31, John Baldwin wrote: > On Friday 01 October 2004 12:13 am, Stephan Uphoff wrote: > > On Wed, 2004-09-29 at 18:14, Stephan Uphoff wrote: > > > I was looking at the MUTEX_WAKE_ALL undefined case when I used the > > > critical section for turnstile_claim(). > > > However there are bigger problems with MUTEX_WAKE_ALL undefined > > > so you are right - the critical section for turnstile_claim is pretty > > > useless. > > > > Arghhh !!! > > > > MUTEX_WAKE_ALL is NOT an option in GENERIC. > > I recall verifying that it is defined twice. Guess I must have looked at > > the wrong source tree :-( > > This means yes - we have bigger problems! > > > > Example: > > > > Thread A holds a mutex x contested by Thread B and C and has priority > > pri(A). > > > > Thread C holds a mutex y and pri(B) < pri(C) > > > > Thread A releases the lock wakes thread B but lets C on the turnstile > > wait queue. > > > > An interrupt thread I tries to lock mutex y owned by C. > > > > However priority inheritance does not work since B needs to run first to > > take ownership of the lock. > > > > I is blocked :-( > > Ermm, if the interrupt happens after x is released then I's priority should > propagate from I to C to B. There is a hole after the mutex x is released by A - but before B can claim the mutex. The turnstile for mutex x is unowned and interrupt thread I when trying to donate its priority will run into: if (td == NULL) { /* * This really isn't quite right. Really * ought to bump priority of thread that * next acquires the lock. */ return; } So B needs to run and acquire the mutex before priority inheritance works again and does not get a priority boost to do so. This is easy to fix and MUTEX_WAKE_ALL can be removed again at that time - but my time budget is limited and Peter has an interesting bug left that has priority. > If the interrupt happens before x is released, > then the final bit of propagate_priority() should handle it since it resorts > the turnstile's thread queue so that C will be awakened rather than B. Agreed. Stephan