On Fri, 2014-08-08 at 13:11 -0700, Sergey Oboguev wrote: > On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith <umgwanakikb...@gmail.com> > wrote: > > > task priority cannot be used by any task to describe a critical section. > > I assert that is that there is _zero_ critical section information present. > > This appears to be the crux of our disagreement. > > This assertion is incorrect. The use of RT to bracket a critical section > obviously _does_ provide the following information:
You sure don't give up easy. > 1) designation of entry point for the start of critical activity Yup, a task can elevate its priority upon entering scram_reactor(), iff it gets there, scram might still be considered a critical activity. > 2) designation of exit point, albeit with timing not known in advance at entry > time Yeah, exit works ok if enter happens. You are not going to convince me that it is cool to assign an imaginary priority to a SCHED_FIFO class task, and still call the resulting mutant a SCHED_FIFO class task. Those things have defines semantics. It is not ok for a SCHED_FIFO task of a lower priority to completely ignore a SCHED_FIFO task of a higher priority because it's part of an application which has one or more wild cards, or maybe even a get out of jail free card it can pull out of its butt. NAK. There it is, my imaginary NAK to imaginary realtime priorities :) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
