From owner-freebsd-hackers Thu May 23 17:21:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id DA17737B40E; Thu, 23 May 2002 17:21:42 -0700 (PDT) Received: from pool0171.cvx21-bradley.dialup.earthlink.net ([209.179.192.171] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17B2pq-0001Re-00; Thu, 23 May 2002 17:21:35 -0700 Message-ID: <3CED876E.3DD4511F@mindspring.com> Date: Thu, 23 May 2002 17:21:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: freebsd-hackers@FreeBSD.ORG, dufault@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_fork.c References: <200202190315.g1J3FSV14877@freefall.freebsd.org> <20020524080444.R8148@gsmx07.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Jeremy wrote: > [I don't have the RT extensions enabled because there was a past thread > about them being susceptable to priority inversion deadlocks - is this > still true]. You are succeptible to such deadlocks no matter what. Priority inversion deadlock only occur in the "spin" case anyway, where the higher priority process is scheduled to run because it's runnable, rather than waiting pending the release of a contended resource. Basically, this only happens if the wait ends up being in user space, which makes it a coding error, and not a kernel problem (e.g. the high priority process is spinning on a resource availability which will never happen because the spinning process never gives the lower priority process a chance to run so that it can release its lock on the contended resource). This is the result of bad design. The only sure cures are priority lending (which can't fix a logic error), resource preemption (which requires a rewrite of a lot of code), resource precommit (Djikstra's "Banker's Algorithm", which overcommits unnecessarily), and avoiding the problem in the first place (which would, again, require a rewrite of a lot of code). So disabling the RT extensions isn't going to save you from deadlocks. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message