Re: [Xenomai-core] Prio-inversion on cleanup?

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

Jan Kiszka wrote:
> ...
> The pthread is blocked on the irqbench device ioctl. On hitting ^C,
> close() is invoked from the main thread for that device. The pthread is
> woken up and obviously relaxed on some linux syscall (after being
> interrupted twice by the periodic timer event of a "latency -p 300 -P
> 50" instance). This passes the control over to the main thread while
> keeping the pthread prio of 99. And this prio seems to survive for the
> following 11 ms (full trace available on request).
> 
> Any ideas what's going on?
> 

Ok, I think I finally understood the issue. It seems to lie deep in the
POSIX user-space lib, specifically its use of standard pthread services.
Let me first clarify my scenario:

A high-prio pthread of known and (theoretically) bounded workload shall
be started and stopped while a low-prio thread is already running. The
low-prio thread shall only be impacted by the real workload of the
high-prio one, not by its creation/destruction - at least not
significantly. To achieve this with the POSIX skin (actually this
applies to preempt-rt in theory as well), I have to create the thread
under SCHED_OTHER, raise its priority right before entering the
workload, and lower it again before leaving the thread.

But, unfortunately, __wrap_pthread_setschedparam() depends on some
real_pthread functions to be called. One of them is
__real_pthread_setschedparam, and this one issues a linux syscall for
obvious reasons. When lowering the thread to SCHED_OTHER, this syscall
is still issued under the original priority. And here we get bitten by
the prio-inheritance feature of the nucleus which, in my case, lets
significant parts of standard Linux execute under high priority,
delaying my other real-time threads.

Now I wonder how to resolve this, how to make pthread_setschedparam (a
rather central RT-service) really real-time safe? I would say we need
something like a lazy schedparam propagation to Linux which only takes
place when the thread enters secondary mode intentionally or no other RT
thread is ready. But I do not have a design for this at hand. Nasty.

[My preferred way for every setup != CONFIG_PREEMPT_RT + CONFIG_XENOMAI
would still be to switch this prio-inheritance off for the root thread.
But this was nack'ed by Philippe several times before... ;)]

Side note: the native skin does not seem to suffer from this effect as
it only tracks the current prio at Xenomai level.

Jan


PS: Gilles, what about marking those services of the POSIX in the doc
that may issue a linux syscall (and under which conditions)?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]