Date: Thu, 23 May 2002 17:21:02 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: freebsd-hackers@FreeBSD.ORG, dufault@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_fork.c Message-ID: <3CED876E.3DD4511F@mindspring.com> References: <200202190315.g1J3FSV14877@freefall.freebsd.org> <20020524080444.R8148@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CED876E.3DD4511F>