Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751369AbVLQDNg (ORCPT ); Fri, 16 Dec 2005 22:13:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751368AbVLQDNg (ORCPT ); Fri, 16 Dec 2005 22:13:36 -0500 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:36251 "EHLO ms-smtp-01.nyroc.rr.com") by vger.kernel.org with ESMTP id S1751365AbVLQDNf (ORCPT ); Fri, 16 Dec 2005 22:13:35 -0500 Date: Fri, 16 Dec 2005 22:13:14 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Linus Torvalds cc: Joe Korty , Thomas Gleixner , Geert Uytterhoeven , Andrew Morton , linux-arch@vger.kernel.org, Linux Kernel Development , matthew@wil.cx, arjan@infradead.org, Christoph Hellwig , mingo@elte.hu, Alan Cox , nikita@clusterfs.com, pj@sgi.com, dhowells@redhat.com Subject: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation In-Reply-To: Message-ID: References: <20051215112115.7c4bfbea.akpm@osdl.org> <1134678532.13138.44.camel@localhost.localdomain> <1134769269.2806.17.camel@tglx.tec.linutronix.de> <1134770778.2806.31.camel@tglx.tec.linutronix.de> <1134772964.2806.50.camel@tglx.tec.linutronix.de> <20051217002929.GA7151@tsunami.ccur.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1655 Lines: 40 On Fri, 16 Dec 2005, Linus Torvalds wrote: > > On Fri, 16 Dec 2005, Joe Korty wrote: > > > > The Mars Pathfinder incident is sufficient proof that some solution to > > the priority inversion problem is required in real systems. > > Ehh. > > The Mars Pathfinder is just about the worst case "real system", and if I > recall correctly, the reason it was able to continue was _not_ because it > handled priority inversion, but because it reset itself every 24 hours or > something like that, and had debugging facilities.. > > The _real_ lesson you should take away from it is not that priority > inheritance is a good solution to priority inversion, but that having a > failsafe switch when everthing goes wrong is critical. You don't know > _what_ bug you'll encounter. > > The bug itself could have been solved without priority inheritance, > although I think in this case enabling that in VxWorks was the particular > solution to the problem as being the least invasive. > > Personally, I don't care what user space does. If some app wants to use > priority inheritance to solve its bugs, that's fine. But it's like > recursive locks: it's generally a _bandaid_ for bad locking. I definitely > don't want the kernel depending on either. So how does one handle real-time tasks that must contend with locks within the kernel that is shared with low priority tasks? Do you prefer the RTAI approach? -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/