[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
RE: [PATCH 2.5.64] Real-time futexes (priority inheritance/protec tion/robust support) take 4
- From: "Alexander Terekhov" <terekhov web de>
- To: phil-list redhat com
- Subject: RE: [PATCH 2.5.64] Real-time futexes (priority inheritance/protec tion/robust support) take 4
- Date: Sat, 29 Mar 2003 19:14:45 +0100
"Perez-Gonzalez, Inaky" schrieb am 27.03.03 20:53:09:
[...]
> > Given: three threads A > B > C [priority wise], the PI
> > lock L1 and the PP lock L2. The locks are used as follows:
> >
> > thread A: L1
> > thread B: L2
> > thread C: L1, L2 [nested].
> >
> > The L2's ceilings is set to prty(B).
> >
> > t1: C locks L1 and gets preempted by now-ready-to-run B
> >
> > t2: B locks L2 and gets preempted by now-ready-to-run A
> >
> > t3: A attempts to lock L1... now A gets blocked on the
> > PI lock L1 and thread C inherits the A's priority
> >
> > t4: C gets scheduled and attempts to lock L2... L2 is a
> > PP lock (note that its ceiling is now less than C's
> > effective priority which is now equal to prty(A)).
> > L2 is currently locked by B. Now, let's assume that
> > you'll allow it to proceed despite a "ceiling
> > violation" (you'll use the C's "static" priority).
> > Thread C gets blocked on the PP lock L2.
> >
> > t5: B gets scheduled and runs, runs, runs... uhmm, and
> > The Mars Pathfinder mission fails: ;-)
>
> Well, let me see if I screwed up something here, but, in t5 both C and B
> acquired L1 and L2; A was blocked by L1 on t3 and C was blocked by L2 on t4
> so it makes sense that B runs, and runs, and runs, ... I don't think it is
> "conceptually" wrong [although I really think it is _not_ something you
> should do in a design] - for starters, mixing pi and pp - and sure the
> timings would be wrong or B will keep going until B ends its thing and
> unlocks. What's wrong?
If you'd allow C to block on L2 using its "static priority" then
C wouldn't preempt B after B unlocks L2. Even if you'd use the C's
"effective priority" (relying on priority ordered wakeup with
preemption on unlock), another thread (say "X") with a priority
"prty(A) > prty(X) > prty(B)" may preempt B and that might result
in unbounded priority inversion problem with respect to A. OTOH,
things just can't go wrong if you'd use effective priorities and
when "ceiling(L2) >= effective_prty(C)". Correct?
regards,
alexander.
______________________________________________________________________________
Mit der Auslands-SMS von WEB.DE FreeMail erreichen Sie Ihre Freunde auf
der ganzen Welt - http://freemail.web.de/features/?mc=021171
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]