Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261961AbVDKXLe (ORCPT ); Mon, 11 Apr 2005 19:11:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261982AbVDKXLe (ORCPT ); Mon, 11 Apr 2005 19:11:34 -0400 Received: from smtp.Lynuxworks.com ([207.21.185.24]:26116 "EHLO smtp.lynuxworks.com") by vger.kernel.org with ESMTP id S261961AbVDKXLc (ORCPT ); Mon, 11 Apr 2005 19:11:32 -0400 Date: Mon, 11 Apr 2005 16:11:55 -0700 To: "Perez-Gonzalez, Inaky" Cc: "Bill Huey (hui)" , Ingo Molnar , Sven-Thorsten Dietrich , Daniel Walker , linux-kernel@vger.kernel.org, Steven Rostedt , Esben Nielsen , Joe Korty Subject: Re: [PATCH] Priority Lists for the RT mutex Message-ID: <20050411231155.GC11685@nietzsche.lynx.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i From: Bill Huey (hui) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1683 Lines: 35 On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote: > If you are exposing the kernel locks to userspace to implement > mutexes (eg POSIX mutexes), deadlock checking is a feature you want > to have to complain with POSIX. According to some off the record > requirements I've been given, some applications badly need it (I have > a hard time believing that they are so broken, but heck...). I'd like to read about those requirements, but, IMO a lot of the value of various priority protocols varies greatly on the context and size (N threads) of the application using it. If user/kernel space have to be coupled via some thread of execution, (IMO) then it's better to seperate them with some event notification queues like signals (wake a thread via an queue event) than to mix locks across the user/kernel space boundary. There's tons of abuse that can be opened up with various priority protocols with regard to RT apps and giving it a first class entry way without consideration is kind of scary. It's important to outline the requirements of the applications and then see what you can do using minimal synchronization objects before exploding that divide. Also, Posix isn't always politically neutral nor complete regarding various things. You have to consider the context of these things. I'll have to think about this a bit more and review your patch more carefully. I'm all ears if you think I'm wrong. bill - 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/