lkml.org 
[lkml]   [2004]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.114 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site