[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

> -----Original Message-----
> From: Alexander Terekhov [mailto:terekhov web de]
> "Perez-Gonzalez, Inaky" schrieb am 27.03.03 02:18:29:
> >
> > And here is the culprit: if now C acquires L1, now prio(C)=prio(A)
> > and it would have violated that C could not have acquired L2 because its
> To me, "would have violated" doesn't really matter here.
> Why does this kinda-"bother" you?

Call me chicken - well, at least now having had somebody publicly reviewing
my rants makes it easier to decide :] so if sometime I get blamed, I can
also point at you :) :)

Screw it! Way to go. Thanks for pushing 

> > This is another one; it may cause mysterious errors really difficult to
> > diagnose, like for example, now I can acquire it and now not because
> just at
> > millisecond 4.5 there was thread Z with highest priority boosting me on
> the
> > lock L I have that it wants, and thus, I wasn't able to acquire the pp
> > futex.
> Do you mean something along the lines of the scenario
> below? Well, the pthread_mutex_setprioceiling() function
> can be used to adjust the ceiling, I guess.

Yep, but then you break the magic - AFAIK, the idea behind the prio ceiling
is that you know in advance the prios of all the threads in the system - of
course, by mixing pi and pp we have already violated this law so what the
hell; if you don't want that, don't mix them. EOD ... I think it is easier,
and at the end, the behaviour you defend makes more sense.

> Well, consider:
> 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? Somebody screwed up the timings (you, in this case

In case we had not allowed it, in t4 C would have failed, but B would still
be holding the lock and doing its thing; now C would need to start recovery:
what type? Just retry later? Kill B? isn't it at the end more expensive than
just waiting for the lock?

Hmmm, this is an interesting case ... would like to see POSIX being more
concrete about this crap


Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]