RE: [PATCH 2.5.64] Real-time futexes (priority inheritance/protec tion/robust support) take 4

["Perez-Gonzalez, Inaky" <inaky perez-gonzalez intel com>]

> -----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).

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

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.

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) ...

Ideas?

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