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:2.493 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site