[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

"Perez-Gonzalez, Inaky" schrieb am 27.03.03 02:18:29:
> > -----Original Message-----
> > From: Alexander Terekhov [mailto:terekhov web de]
> > 
> > "Perez-Gonzalez, Inaky" schrieb am 25.03.03 00:54:05:
> > [...]
> > > I reached the conclusion that you can only hold more than
> > > one pp mutexes only if they have the same prio ceiling,
> > 
> > Uhmm, "only if they have the same prio ceiling"...
> > 
> > Given: three threads A > B > C [priority wise] and two PP
> > locks L1 and L2. The locks are used as follows:
> > 
> >   thread A: L1
> >   thread B: L2
> >   thread C: L2, L1 [nested].
> > 
> > The assigned ceilings are:
> > 
> >   L1: prty(A)
> >   L2: prty(B)
> > 
> > To me, this looks just fine. Note that if thread C would
> > have "L1, L2" locking order, then according to my reading
> > of the standard, the L2-ceiling would have to be raised to
> > prty(A) (otherwise, implementation would fail with EINVAL
> > on an attempt to lock L2). Or am I just missing and/or
> > misunderstanding something?
> That's it: so the consequence is that thread C can only acquire locks L1 and
> L2 if their prio ceiling is the same (for the case L1 then L2).

Nah, ceiling(L1) <= ceiling(L2). ;-)

> Now, in the case L2 then L1, when C acquires L2, prio(C)=prio(B) < prio(A),
> right? 


> 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?

> prio is higher than the ceiling. This is what I am trying to interpret ...
> should I allow this or not?
> Somehow, I think I should, but I am not truly positive about it.

I think you should.

> Same thing applies to setting the priority of the thread to something higher
> than the prio ceiling while it holds the futexes; and same thing applies to
> thread C holding also a pi futex that will cause it to be boosted over the
> prio ceiling.
> > > and also that the priority boosts you can get can only
> > > be up to the priority ceiling.
> > 
> > I'd rather "don't care" and "allow" it to fail with EINVAL
> > on an attempt to lock a PP mutex if thread's {"effective"}
> > priority is higher than the mutex's ceiling. Oder?
> 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.

> Or the other way around [if forbidden to do that] - thread Z goes on to
> lock, but the priority boost fails because lock L is owned by some thread
> who is holding a pp futex with prio ceiling lower than my priority.
> So maybe instead of the effective priority I want to use the static
> (rt_priority) ...

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: ;-)


So, unless I'm just missing and/or misunderstanding 
something, I guess that reporting EINVAL failure 
instead of "just letting it continue" would probably be 
more helpful, so to speak (it would cause "faster" 
restarts/whatever-recovery-actions, for example).

> Ideas?

I'd stick to effective priority checking and do the rest 
according to the spec.


Mit der Gruppen-SMS von WEB.DE FreeMail erreichen Sie mit einem Klick 
alle Freunde gleichzeitig! http://freemail.web.de/features/?mc=021180

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