On Thu, 2006-06-29 at 11:24 +0200, Jan Kiszka wrote:
> 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... ;)]

I nacked the proposal to _always_ switch it off. Some applications
deeply need this.

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

Switching off priority adjustment for the root thread before moving a
SCHED_FIFO shadow to SCHED_OTHER would prevent this side-effect. We'd
need to add a per-thread status bit to check whether we should run
xnpod_renice_root() or not for any given thread, and switch it on/off
from __wrap_pthread_setschedparam.


Xenomai-core mailing list

Reply via email to