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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
