On Fri, 2005-02-25 at 15:53 +0000, Paulo Marques wrote: > Ingo Oeser wrote: > > Chris Friesen wrote: > > > >>Ingo Oeser wrote: > >>[...] > > You would need to change the priority of task 1 until it releases the > > mutex. Ideally the owner gets the maximum priority of > > his and all the waiters on it, until it releases his mutex, where he regains > > its old priority after release of mutex. But this priority elevation happens > > only, if he is runnable. If not, he gets his old priority back, until he is > > runnable. > > This is called a "priority inversion" problem, and there was some work > done by Ingo Molnar to make the scheduler aware of such cases and handle > them appropriatelly. > > You can follow this thread for more info: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110106915415886&w=2 >
The solution to your problem (which is as old as the hills) involves priority inheriting mutexes which are available in the RT preempt patch (if you build with CONFIG_PREEMPT_RT). This should be usable for hard realtime applications. http://people.redhat.com/mingo/realtime-preempt If you just need very good soft realtime performance I recommend PREEMPT_DESKTOP. Lee - 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/
