Messages in this thread | | | Date | Fri, 26 Nov 2004 21:41:38 +0100 | From | Ingo Molnar <> | Subject | Re: Priority Inheritance Test (Real-Time Preemption) |
| |
* Esben Nielsen <simlo@phys.au.dk> wrote:
> > task-A task-B task-RT > > > > spin_lock(&lock2); > > [ gets lock2 ] > > spin_lock(&lock1); > > [ gets lock1 ] > > spin_lock(&lock2); > > [ boosts task-A ] > > [ waits ] > > [ gets RT prio ] . > > spin_lock(&lock1); . > > [ boosts task-B ] . > > [ waits ] . > > . [ gets RT prio ] . > > . [ 1 msec loop ] . > > . spin_unlock(&lock1); . > > [ gets lock 1 ] . > > spin_lock(&lock1); . > > point of disagreement ----^
> No :-)
> Why should task B get lock1 the 2. time before the rt-task? That would > be an error!
then make it task-C, which tried to take the lock before the RT task came into the picture. Btw., the above scenario can still happen on SMP.
when task-A unlocks lock1, it can very well give it to task-C - there's no reason not to do it, task-RT has not expressed any interest in lock1 yet.
so my example and analysis still stands.
> I can't see how it can produce a flow like the one you describe above!
it can produce such a flow on SMP, or if you add in a third non-RT task (task-C). Agreed?
In the test where you got 3 msecs you had more than 2 non-RT tasks, correct?
Ingo - 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/
| |